Redesign `RetryPolicy` to directly incorporate `BackOff`

[sbrannen]

Overview

After experimenting with our newly introduced core retry support (RetryPolicy, RetryTemplate, etc.) and @Retryable support, it has become apparent that there are overlapping concerns between the current RetryPolicy and BackOff contracts.

1. RetryPolicy and BackOff both have stateful executions: RetryExecution and BackOffExecution. However, only one stateful execution is necessary.
2. FixedBackOff and ExponentialBackOff already incorporate "retry" logic in terms of max attempts, max elapsed time, etc. Thus, there is no need to duplicate such behavior in a RetryPolicy and its RetryExecution.
3. RetryTemplate currently accepts both a RetryPolicy and a BackOff in order to instrument the retry algorithm. However, users would probably rather focus on configuring all "retry" logic via a single mechanism.

Deliverables

In light of the above, we have decided to directly incorporate BackOff in RetryPolicy. To achieve that, we will do the following.

• Remove the RetryExecution interface and move its shouldRetry() method to RetryPolicy, replacing the current RetryExecution start() method.
• Introduce a default getBackOff() method in the RetryPolicy interface.
• Completely overhaul the RetryPolicy.Builder to provide support for configuring a BackOff strategy.
• Remove BackOff configuration from RetryTemplate.

Related Issues

• Introduce minimal retry functionality as a core framework feature #34716
• Introduce @Retryable AOP support (based on core.retry and Reactor retry functionality) #34529
• Introduce Builder API and factory methods for RetryPolicy #35058