Is your feature request related to a problem? Please describe.

The scenario where you want to retry a message X number of times and for each time you want to have an exponential backoff is possible today using a combination of DLX, Queue TTL and a number of queues per retry but it is a hassle of setting everything up and adds logic to the consumer to keep track of all this.

Describe the solution you'd like

The feature activates when a user declares a queue with x-retry-max-count set. The broker recognizes this argument and automatically provisions the retry infrastructure. Four queue arguments control the behavior:

• x-retry-max-count (integer, required to enable): Maximum retry attempts before final dead-lettering, e.g., 5
• x-retry-delay (integer, ms, default 1000): Initial backoff delay
• x-retry-delay-multiplier (integer or float, default 2): Exponential multiplier
• x-retry-max-delay (integer, ms, default 60000): Delay cap preventing excessively long waits

The message flow on rejection proceeds as follows. When a consumer calls basic.reject or basic.nack with requeue=false, the broker inspects the queue's arguments. If x-retry-max-count is present, the broker reads the x-retry-count header from the message (defaulting to 0 if absent). If the count is below the maximum, the broker increments it, sets it on the message, and routes the message to the appropriate internal retry queue. The message sits in the retry queue until its TTL expires, then dead-letters back to the primary queue for redelivery. If the retry count equals or exceeds the maximum, the broker routes the message to the user-configured x-dead-letter-exchange (if present) or discards it — this makes the DLX the "final" dead-letter destination, which is intuitive and consistent with how users already think about DLX as the place messages go when they cannot be processed.