feat(codegen): fill URI/endpoint-bound members for the CRaC warm-up call and warm sync/async clients independently

[joviegas]

Motivation and Context

The CRaC warm-up selector did not select an operation that has a required member bound to the URI path or to an endpoint context param. These members do not accept null. Some services have this member on every candidate operation. For these services, the selector found no operation. Thus the SDK did not prime the marshalling path or the signing path before the checkpoint.

Also, warmUp() warmed the sync client and the async client in one flow. If one client failed, the other client did not warm.

Modifications

• Selector (WarmUpOperationSelector): Accept an operation when all of its required URI/endpoint-bound members are of type String. The allDummyMembersAreFillable gate does this check. Add the membersRequiringDummyValue helper and the isArnMember helper.
• Emitter (WarmUpProviderSpec): Emit a dummy value for each required bound member. Use "warmup" for a plain member. Use an ARN value for an ARN member. Move the client build into the shared clientBuilder helper and the addServiceSpecificOptions helper (bearer token, endpoint-discovery disable). The sync path and the async path share these helpers.
• Isolation (SdkWarmUpProvider.warmUp(), TargetedWarmUpInvoker): Route both paths through the shared WarmUpDiscovery.runSafely(description, task) helper. The sync client and the async client warm on their own. If one client fails, the SDK writes a warn log and continues to warm the other client.

Modules that always need each fix

Fix A. Dummy value for a required URI-path or endpoint-bound member. These modules have a required member that the marshaller rejects on null. They now get .member("warmup").

These modules need a dummy value for a required URI-path member: apigatewaymanagementapi, iotjobsdataplane, lexruntime, lexruntimev2, quicksight, sagemakerruntime, sagemakerfeaturestoreruntime, workmailmessageflow, ebs, chimesdkmeetings, amplifyuibuilder, marketplacedeployment, eksauth, geomaps, transcribestreaming.

One module needs a dummy value for an endpoint context param:

Module	What it needs
s3control	Dummy value for the AccountId endpoint context param (validated only as a host label, so "warmup" works)

Fix A. Bearer-token auth.

Module	What it needs
codecatalyst	Resolves a token, not sigv4 creds. Emits .tokenProvider(StaticTokenProvider.create(() -> "warmup-dummy-token")) so it does not fall through to the profile/SSO token chain and fail.

Fix B. Endpoint-discovery WARN suppression.

Module	What it needs
timestreamwrite	Emits .endpointDiscoveryEnabled(false) to stop the client constructor logging a WARN about the endpoint override disabling discovery
timestreamquery	Same as above

Testing

• Junits

License

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

[joviegas]

This behaviour is same ad before, as part of this PR moved it to a function so that this can be resused.

[RanVaknin]

The required input members the warm-up call must give a dummy value.

Nit: grammar is incorrect (?) reads funny.

[RanVaknin]

How did we discover this? Was this just a manual check to see which services have code generated a warmup call and which ones didnt?

Did we do the same check after this PR to check if there are any remaining gaps?

[RanVaknin]

Do you know how accurate this endsWith signal is? This heuristic seems like an ok signal, but I'm worried about edge cases that this might miss. For example S3 Bucket can accept an ARN so it wont end with "arn".
I think we can use the model's endpoint ruleset for a more authoritative source of whether a member is an arn:

  {
      "fn": "aws.parseArn",
      "argv": [
          {
              "ref": "Bucket"
          }
      ],
      "assign": "bucketArn"
  }

To be completely honest I don't know if this edge case is even applicable here. For all intents and purposes a heuristic endsWtih("Arn") might be good enough. Can you just verify?