Skip reconnect delay on first reconnect attempt

[timbussmann]

An idea to improve the behavior when using message throughput throttling in which case the implementation always triggers a reconnect. The default implementation then by default waits 10 seconds causing an unexpected delay in immediate retry processing attempts.

At first thought, the first reconnect attempt can be attempted without any delay, while bringing in the delay in case the first reconnect attempt fails.

Not quite sure if that would cause issues with other calls to Reconnect, e.g. in Channel_ModelShutdown, Connection_ConnectionShutdown, and Consumer_ConsumerCancelled though.

Any thoughts on this?

[timbussmann]

on playing with this setting a bit further, a problem that needs to be taken into account is that closing the connection will make all the inflight messages immediately reappear on the new connection. Without the delay, this will increase the chance of multiple active processing pipelines that are processing the same message. While the 10 second delay does not fully prevent that, it's likely that it will at least reduce such scenarios.

[timbussmann]

closing this as the 10 second delay is currently not necessarily bad to prevent duplicate messages as described on this comment. While the approach proposed in #1258 can gracefully handle the scenario by draining the in-flight messages before reconnecting.