This PR tries tofix#53216 and is a follow-up to#51815
It is somewhat of a stretch to call this a fix, as it changes behaviorand 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 lastReceivedStamp in order to not lose information about the original transport
  • It is assumed that theFailedMessageProcessingMiddleware 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 defaultMutliplierRetryStrategy counts allRedeliveryStamps 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
• TheAmqpSender 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 defaultfanout binding setup, but interferes with routing in the delay exchange

Limitations:

• countingRedeliveryStamps is not reliable asSendFailedMessageForRetryListener limits (removes) them
  • this could be solved by including a total instead of just the current in theRedeliveryStamp

Changing the retry behaviorand 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!