This PR tries to fix #53216 and is a follow-up to #51815
It is somewhat of a stretch to call this a fix, as it changes behavior and especially breaks the BC promise.
My sole argumentation for a fix would be that discarding instead of retrying messages is unexpected behavior, but this is subjective.
With changed behavior, I am very much open for comments and suggestions.

The changes are:

• SendFailedMessageToFailureTransportListener does no longer discard messages if a message was already sent to a failure transport but uses a retry strategy to re-send it to the failure transport using an increasing delay
  • Messages will be retried indefinitely until successfully handled
• SendFailedMessageToFailureTransportListener uses the last ReceivedStamp in order to not lose information about the original transport
  • It is assumed that the FailedMessageProcessingMiddleware is used
  • Otherwise e.g. a handler that is only registered for a specific transport (from_transport) would not be considered as a handler when retrieving retries from a failure transport
• The default MutliplierRetryStrategy counts all RedeliveryStamps to determine the delay instead of the current retry loop
  • Reasons:
    • My argument would be that the delay should increase with every subsequent retrieval from the failure queue, regardless of the current retry in the retry strategy
    • A retry strategy with 0 retries would always use the default without increasing at all
• The AmqpSender does no longer default to where a message was previously received from as a routing key, when sending it to the failure transport
  • This did not really matter with the default fanout binding setup, but interferes with routing in the delay exchange

Limitations:

• counting RedeliveryStamps is not reliable as SendFailedMessageForRetryListener limits (removes) them
  • this could be solved by including a total instead of just the current in the RedeliveryStamp

Changing the retry behavior and the public constructor of the EventListener is definitely a breaking change. It's impossible to tell if a project relies on the fact that messages are discarded from the failure transport.
The constructor change is handled gracefully but it still requires some sort of default delay in order to not introduce the regression of an instant and infite retry loop.

Again, really happy for feedback!