Enable compiled endpoint rules for all services and fix regionId parameter mismatch bug

[S-Saranya1]

Motivation and Context

Compiled endpoint rules generate endpoint resolution logic as direct Java code at codegen time, rather than interpreting rules at runtime. This provides ~40% better performance. The feature was behind a flag (enableGenerateCompiledEndpointRules) and already enabled for 344 services externally. This PR enables it for all remaining internal services by flipping the flag to true.

However, simply flipping the flag exposed a bug in the compiled endpoint provider codegen. The resolveEndpoint method extracts the region as a local String variable and always passes it to the root rule method:

Region region = params.region();
String regionId = region == null ? null : region.id();
RuleResult result = endpointRule0(params, regionId);  // always 2 args

But the root rule method's signature is generated based on scope analysis, it only includes regionId as a parameter if that method directly uses it. For most services, the root rule directly uses region (e.g., to look up the partition), so the 2-arg call matches:

private static RuleResult endpointRule0(Params params, String regionId) { ... } // 2 params - works

But for some services, the root rule just delegates to a child rule without using region itself:

private static RuleResult endpointRule0(Params params) { ... } // 1 param - compile error!

This creates a mismatch: the call site passes 2 arguments but the method only accepts 1.

This PR fixes the bug by adding a regionId() method to the endpoint params class that returns the region as a String (null-safe). The codegen now emits params.regionId() wherever the rules need the region as a string, eliminating the local variable and the parameter passing mismatch entirely.

Modifications

• CustomizationConfig.java — Flip enableGenerateCompiledEndpointRules default from false to true
• EndpointProviderSpec2.java — Remove region local variable extraction (Region region = params.region(); String regionId = ...) from resolveEndpointMethod(). Update initSymbolTable() to mark region params via addRegionParam() instead of creating a local
• SymbolTable.java — Replace String regionParamName with Set<String> regionParams. Add isRegionParam() and addRegionParam() methods
• CodegenExpressionBuidler.java — Remove regionParamName() accessor
• RenameForCodegenVisitor.java — When the referenced param is a region param, emit params.regionId() (append "Id" to accessor name) instead of params.region()
• EndpointParametersClassSpec.java — Generate regionId() method for Region-typed params: return region == null ? null : region.id()
• AuthSchemeParamsSpec.java — Add regionId() default method to the interface
• DefaultAuthSchemeParamsSpec.java — Add regionId() override
• EndpointRulesSpecUtils.java — Add directory fallback to rulesEngineResourceFiles2() so compiled rules codegen works when running from exploded classes in test environments

Testing

• All existing tests pass
• Golden file tests updated to verify generated code uses params.regionId() pattern
• Added runtime tests for regionId() (null and non-null cases)
• Dry-run build to live on build.amazon.com passed for AwsJavaSdk-Codegen

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

[RanVaknin]

The current test suite doesn't cover the scenario that was actually broken. All existing fixtures use services that reference the region, so they only exercise the happy path.

Could you add coverage for a service that declares a Region parameter but never uses it in its rules (with enableGenerateCompiledEndpointRules": true)?

[S-Saranya1]

The current test suite doesn't cover the scenario that was actually broken. All existing fixtures use services that reference the region, so they only exercise the happy path.

Could you add coverage for a service that declares a Region parameter but never uses it in its rules (with enableGenerateCompiledEndpointRules": true)?

Good point, added a test with a service model where the root rule delegates without directly using region.