Remove resolveClientEndpointProvider from AwsDefaultClientBuilder

[S-Saranya1]

Motivation and Context

This PR has two changes:

AwsDefaultClientBuilder.resolveClientEndpointProvider() was triggering GeneratedServiceMetadataProvider initialization (~350ms) during every client creation. Although registered via lazyOptionIfAbsent as a fallback for older clients, AttributeMap.build() eagerly resolves all lazy values — causing the fallback to execute even when the generated builder already set CLIENT_ENDPOINT_PROVIDER. All generated clients have set it themselves since 2024, making this fallback dead code with a significant performance cost.

Additionally, AwsClientEndpointProvider.build() is the method that calls ServiceMetadata.of() and triggers the expensive initialization. After our changes across PRs #7094, #7105, #7110, #7168, no code path in client creation calls it anymore. Deprecating it signals to not use and use resolveFromOverrides() + service EndpointProvider instead, and prevents accidental re-introduction of the performance issue.

Modifications

• Removed resolveClientEndpointProvider() method and its lazyOptionIfAbsent registration from AwsDefaultClientBuilder.finalizeAwsConfiguration()
• Removed unused AwsClientEndpointProvider import and DEFAULT_ENDPOINT_PROTOCOL constant
• Added null validation in resolveEndpoint() and resolveEndpointOverridden() with clear error message for custom clients that don't set CLIENT_ENDPOINT_PROVIDER
• Deprecated AwsClientEndpointProvider.build() — points users to resolveFromOverrides() + service EndpointProvider instead
• Updated TestClientBuilder and TestAsyncClientBuilder in tests to set CLIENT_ENDPOINT_PROVIDER in finalizeServiceConfiguration(), mirroring what real generated builders do
• Bumped S3 test dependency from 2.20.136 to 2.28.1 — old version didn't set CLIENT_ENDPOINT_PROVIDER in its builder, which now fails because we removed the resolveClientEndpointProvider() fallback from AwsDefaultClientBuilder.

Testing

• All 32 existing tests in DefaultAwsClientBuilderTest pass
• Tests updated to set CLIENT_ENDPOINT_PROVIDER directly (same pattern as generated builders)

Screenshots (if appropriate)

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

[joviegas]

Could you elaborate on why these tests are failing? I would also like to understand when a customer would hit this. Does the failure occur when someone uses a service client from 2.20.136 together with the newer core modules, which is what this test module sets up? In other words, what exactly exposes the backward incompatibility and whats the error message?

If we have decided that this break is acceptable for 2.20.136, then I think we need to do two things to address it correctly. First, we should either remove the test/old-client-version-compatibility-test module, since we no longer expect compatibility, or keep it and assert the failure as the expected behavior. Second, we should announce this breaking change usign github announcement (this can be done just before releasing the feature)