Revise default settings for Delayed Delivery

[bording]

#329 introduced two new settings to control the backwards compatibility of the delayed delivery feature, DisableTimeoutManager and AllEndpointsSupportDelayedDelivery. These settings default to being false to maximize compatibility with endpoints that haven't been upgraded yet.

We should consider revising the default values and/or removing these settings in the 5.0 time frame.

Plan of attack

• make changes Disable timeout manager by default #469
• update docs Document new RabbitMQ default behavior and EnableTimeoutManager API docs.particular.net#3600

[bording]

The AllEndpointsSupportDelayedDelivery was removed because of #367, but we do have #370 to consider adding it back in some form.

[bording]

Going to add this back to 5.0.0 for now so we can discuss options around how to achieve this, including making Disable/Enable mandatory now to enable an obsolete in the future.

[adamralph]

Discussed again today. One idea is the following:

In 5.0.0:

• Introduce a new UseLegacyTimeoutManager(bool) (exact name TBD, perhaps UseHybridTimeouts or similar)
• Throw an exception if the new method is not called

In 6.0.0:

• Remove the exception throwing
• Deprecate UseLegacyTimeoutManager(bool) with an error
• Introduce a new EnableLegacyTimeoutManager() (or similar)

The problem with this solution is that it enforces the calling of a new method to every user of the transport. We need to give this some more thought before going ahead.

AllEndpointsSupportDelayedDelivery or its equivalent should be considered in a separate issue, if at all. It may not be worth pursuing that.

[bording]

@Particular/rabbitmq-transport-maintainers I've been thinking about this one some again, and I think we might want to reconsider doing this as part of 5.0 after all.

[adamralph]

@bording I've added back to the 5.0.0 milestone to ensure that we at least consider it again.

[bording]

The revised plan is to go ahead and change the behavior in 5.0.0 to disable the timeout manager by default, and add an API to opt-in to backwards compatible behavior.

We decided this was okay to do in a single major because if someone deployed without calling the new API, no messages in timeout storage would be lost. Adding the call and redeploying would be all that would be required to consume those messages.