Expensive instanciation of RetryPolicyContext upon requestSucceeded

### Describe the bug

The default retry condition combines sub elements that does nothing upon request success.

Yet we pay for every request the price of instanciating the RetryPolicyContext despite not using it. This looks wasteful.

### Expected Behavior

I expect reduced object creation linked to retry policies when my requests succeeds.

### Current Behavior

On a regular IMAP workload for the [Apache James](https://james.apache.org) server, I observe 0.74% percent of memory allocation to be caused by retry policy handling.

Note that S3 is only part of the workload, a bench exercising just S3 would actually show higher numbers here.


### Reproduction Steps

Profiling: https://github.com/jvm-profiling-tools/async-profiler

### Possible Solution

- 1. An additional level of indirection in the retry policies could enable passing a `Supplier` wich would both:
- A memoized supplier (a la Guava) that enables not instanciating the RetryPolicyCOntext until it is needed.
- Enable trivial implementation of the existing API to avoid breaking changes

- 2. Avoiding the iterator madness in the defaultRetryCondition.
- This could be done either by emptyness checks before iterations
- Or maybe overloading the `requestSucceeded` of the default retry condition to do nothing.

### Additional Information/Context

_No response_

### AWS Java SDK version used

2.17.189

### JDK version used

openjdk version "11.0.15" 2022-04-19

### Operating System and version

Ubuntu 20.04.4 LTS