Seperate polling interval and retry interval in receiver/listener

### Related Problem or Business Case

When working with pullingListeners such as the MessageStoreListener, you almost always want your polling interval to be much smaller than your retry interval. For example: I would like a polling interval of 30s, but I would like to retry every 15 min or with some sort of backoff perhaps. Currently the retry interval is the same as the polling interval, which means that 5 max retries would be exhausted within 2.5min. This is usually not enough time for upstream services to recover from a temporary issue.

The 'maxBackoffDelay' attribute is also no solution for this as it is capped at the transaction timeout, which is usually < 1min.

Currently we are constantly creating dubious solutions to work around this by setting up a scheduler that triggers at the retry interval and changes the status of the message in the database.

### Describe the Feature

Quick solution could simply be to add a retryInterval attribute + a warning if an incompatible transactionAttribute is used.

Fancy solution could be dedicated RetryStrategy sort of element(s). Would expect a retry functionality to be available in the relevant listener instead of the receiver aswell, as the behavior can be dependent on the type of listener

### Collaboration with External Companies

No, community resolution only

### Anything else?

_No response_

Start by tracing pullingListeners such as MessageStoreListener and the current receiver/listener retry handling. Read how maxBackoffDelay and the transaction timeout constrain retries, then clarify whether the scope is a retryInterval attribute or a broader RetryStrategy. Done should provide independent polling and retry timing, with clear handling or a warning for incompatible transaction attributes.

Written by the indexing model from the issue text.