Default RestryStrategyV2 does not retry on extended `$retryable` error trait

[adrcase-amazon]

Checkboxes for prior research

• I've gone through Developer Guide and API reference
• I've checked AWS Forums and StackOverflow.
• I've searched for previous similar issues and didn't find any solution.

Describe the bug

The deprecated StandardRetryStrategy would allow retrying based on the $retryable trait is not supported by the replacement V2 StandardRetryStrategy.

Regression Issue

• Select this option if this issue appears to be a regression.

SDK version number

@smithy/util-retry@^v4.0.6

Which JavaScript Runtime is this issue in?

Node.js

Details of the browser/Node.js/ReactNative version

v18.20.2

Reproduction Steps

Create custom middleware after the retry middleware. When an error is thrown a $retryable trait will be added to the error with the object

{
throttling: false,
reason: 'some-reason' 
}

When running the attached test files it can be observed that there is only 1 attempt.

retryable-trait-test.zip

Observed Behavior

The error is not retried and only 1 attempt is made.

Expected Behavior

The deprecated StandardRetryStrategy used the retryDecider and calls isRetryableByTrait to retry errors that have the $retryable trait.

The replacement V2 StandardRetryStrategy should still check for the $retryable trait and retry if it is present.

Possible Solution

Allow V2 StandardRetryStrategy to retry on errors tagged with the $retryable trait in the error using the isRetryableByTrait available in the @smithy/service-error-classification package.

OR

Mutate the name of the returned error with some custom middleware before it is processed by the retryMiddleware. I don't think this is recommended because it can cause some confusion for future developers why an error has a name that differs from the actual exception name thrown by the invoked service.

Additional Information/Context

When searching the @aws-sdk-js-v3 package, search, several clients are identified as throwing a defined $retryable trait. This hasn't been failing for those client because the retryMiddleware classifies the error type based on the error name, code pointer. That error classification is used by the V2 StandardRetryStrategy to determine if the error is retryable.