Add a more aggressive retry strategy for cluster operations and handle dead nodes

[CGodiksen]

Currently we just return an error if any cluster operation fails on any node. Instead we should have a more aggressive retry strategy to ensure that cluster operations are forced through and if a node cannot be reached we should handle it.

[CGodiksen]

When we create, drop, and use tables, if we encounter an error, we should try to handle it by synchronizing with the remote data folder.

For example if a node receives data it does not have a table for, check the remote object store for the table. Also, if data transfer fails because the table does not exist in the remote object store, drop it locally.

[skejserjensen]

To me, this seems like two different problems that can both be solved using code generating macros.

In the first, we simply need to retry operations a number of times according to a strategy to ensure something is actually broken such as disk, memory, network, etc, meaning that we actually need to return an error. This seems like something that can be fixed with a declarative macro or a procedural macro, and it seems multiple people already had this idea but none of them seem to be maintained:

• https://github.com/dintegrity/retrying
• https://github.com/bwintertkb/retry_macro
• https://thepacketgeek.com/rust/macros/macro-matching-and-nesting/

The second seems to be a problem specific to ModelarDB, but maybe we can have a synchronization function and then have a macro that executes the function that failed again. Again, it seems writing a declarative macro or a procedural macro for this seems like it would save a lot of repeated code as the pattern will probably be very similar despite the difference in the function being executed.