Add Environment Token support

[alextwoods]

[DO NOT MERGE] Currently diffed against WIP authscheme preference branch. This will need to be rebased against master once PR #6083 has been merged.

Motivation and Context

Adds support for configuring bearer auth using a token sourced from the environment.

Modifications

• Adds customization config to enable environment bearer token support.
• When customization flag is set, the BaseClientBuilder will check if the ENV variable is set, and if so, will configure both a prefered auth scheme (using the mechanism from Adding functionality to config preferred authschemeProvider #6083) and add a static token identity provider.
• Includes additional token identity improvements (improve client configuration).

Testing

• New and existing unit tests
• Manual testing against service endpoints.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• I have read the CONTRIBUTING document
• Local run of mvn install succeeds
• My code follows the code style of this project
• My change requires a change to the Javadoc documentation
• I have updated the Javadoc documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed
• I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
• My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

• I confirm that this pull request can be released under the Apache 2 license

[zoewangg]

Is there a way to not use execution interceptor to capture user agent? We've had issues (executions out of order issue) in the past with doing things in execution interceptor and are moving away from that model for internal implementations

[alextwoods]

Summarizing offline discussion:

The ordering problem is a good callout. The new <service>EnvironmentTokenMetricsInterceptor must run after the service specific, code generated auth scheme interceptor (<Service>AuthSchemeInterceptor). The alternatives I see are:

[non-Interceptor] - Adding logic in a stage in the request pipeline - specifically to ApplyUserAgentStage.

We need to evaluate, per request, whether the configured env token was used (since a request configuration can override it). So, we would need a client configuration thats added to the execution attributes the value of the ENV sourced token. The ApplyUserAgentStage would then check for the presence of this execution context value and if set, would then check the resolved auth is bearer and the resolved identity matches, and if so, set the metric.
Thats logic thats specific to this customization that would then be in core and that check would be done for every service since the pipeline stage is in core and not code generated. I'm not sure how we feel about that tradeoff. I'd generally lean towards trying to keep some of this service specific customization out of the core pipeline.

[Addressing with changes to generated interceptors]
We could address this in a few ways:

1. Move the logic in <service>EnvironmentTokenMetricsInterceptor from beforeExecution to beforeMarshalling. This ensures its in a different step and eliminates ordering concerns.
2. Modifying code generation of the <Service>AuthSchemeInterceptor to include this logic when the customization is enabled. This eliminates any issue with ordering, but isn't an ideal separation of concerns.

For nowI've updated this PR with #1 from above and moved the logic from beforeExecution to beforeMarshalling but I can prototype out the changes required to update the ApplyUserAgentStage though if you think the tradeoffs of having that customization logic in core make sense.

[alextwoods]

Update - I've now updated the PR with alternative 2 mentioned above - I've moved the metrics logic into the generated auth scheme interceptor which will ensure we won't have ordering issues.