Add support for "derived" execution attributes.

[millems]

These execution attributes do not get stored in the execution attribute map. Instead, they read from or write to OTHER execution attributes in the execution attribute map. This allows us to deprecate old execution attributes and keep them in sync with the execution attributes that have replaced them without needing to read or write to the old attributes.

Included in this PR is adding derived execution attributes for all AwsSignerExecutionAttributes, SdkTokenExecutionAttributes and S3SignerExecutionAttributes, as well as deprecation of those classes and their attributes.

Other notable changes:

1. When the SELECTED_AUTH_SCHEME is already set when we execute the auth scheme interceptor, carry forward any properties that were already set in the selected auth scheme. This allows setting those properties using the old execution attributes early in the request pipeline.
2. Add dependency on http-auth-aws and http-auth from auth. This allows the mapping from old attributes to new properties to be defined where the old attributes are created. This also sets us up for a potential future where our existing signers can return a new-style signer.
3. Simplify the decision of when to use the old signing path or the new signing path. For presigners, always use the old signers. For everything else, use the old signers when the customer has overridden the signer OR we're using an old client that doesn't define any auth schemes.

[sonarqubecloud]

SonarCloud Quality Gate failed.   

5 Bugs
0 Vulnerabilities
2 Security Hotspots
409 Code Smells

0.0% Coverage
8.6% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[gosar]

I see this change and related change in (Async)SigingStage that checks IS_NONE_AUTH_TYPE_REQUEST to not sign. But with this approach,

1. For an old client with new core, for operation with authType=none, an unnecessary aws credentials resolution will happen (part of addCredentialsToExecutionAttributes). It adds a potential failure path that shouldn't matter, and this didn't happen earlier, so is a behavior change.
2. For a new client, if customer overrode the Signer at the client level (with the desire to use that Signer for the auth'ed operations), for request that resolves to NoAuthAuthScheme (e.g., authType=none operations), same unnecessary aws credentials resolution will happen, which I was avoiding with the additional conditionals.

[millems]

I missed that nuance - there must not be a test for it, yet. We should fix it and add a test to make sure no one else makes my mistake.

[gosar]

have added internal ticket to track this.

[gosar]

being fixed in #4523

[gosar]

This method is unrelated to endpoint rules, but I guess it is convenient to put this method in endpoint rules related utils class; instead of a new one or generate it in AuthSchemeInterceptorSpec itself.

[gosar]

the putIfAbsent here means if the selectedAuthScheme overwrites the existingAuthScheme's values - this seems fine. IIUC, the only case where existingAuthScheme would be non-null when it reaches this code path would be for attributes set here before calling the AuthSchemeInterceptor (which calls this AuthSchemeUtils) few lines later here.

Though makes me wonder if this method should have comments on appropriate use and prevent it getting used in some other context. Not a big deal I think, though probably another reason to move this method inside AuthSchemeInterceptor.