In Lambda recursion detection middleware, fetch the trace id from context before the environment variable

[bmoffatt]

PLEASE READ BEFORE CONTINUING

DO NOT submit pull requests that directly modify generated source files, e.g. /service/s3/api_client.go. Generated source files will always include an identifying header:

// Code generated by smithy-go-codegen DO NOT EDIT.

Manual changes to these files will be overwritten by code generation that occurs as part of the daily SDK release process.

DO NOT submit pull requests that directly modify files in the /codegen/sdk-codegen/aws-models folder. These are API model files, owned by each AWS service team, that are updated automatically as part of the daily SDK release process. Local changes to these files will not persist.

If you believe the contents of any of these files need to be changed, please open an issue.

If the PR addresses an existing bug or feature, please reference it here.

To help speed up the process and reduce the time to merge please ensure that Allow edits by maintainers is checked before submitting your PR. This will allow the project maintainers to make minor adjustments or improvements to the submitted PR, allow us to reduce the roundtrip time for merging your request.

See issue: #3354

Changelog

Please DO NOT include a changelog entry in your pull request (you may see
what these look like in other PRs submitted directly by SDK team members). We
will take care of this for you.

• Updates aws/middleware/recursion_detection.go to grab the trace ID from ctx.Value("x-amzn-trace-id"), falls back to os.LookupEnv("_X_AMZN_TRACE_ID") for back compat.
• Updates test cases to aws/middleware/recursion_detection_test.go

[lucix-aws]

CI is failing, you can ignore integ/codegen tests but the go tests need to pass

[lucix-aws]

this is fine but we should really be using the context as a fallback, not the env. i don't want the values being swapped out from under anyone on the off chance that they are somehow different today for environments where both would be set. this is also sort of a special implementation detail of go (all the SDKs have this recursion detection and they'd all be looking at the env) so i'd rather have the code do the blessed thing(TM) first and then check the language-specific thing as a followup

[bmoffatt]

Yeah I can flip the order. I suppose that'd be less foot-gun-y for sdk users not using Lambda Managed Instances that are plumbing like context.TODO() instead of the lambda context.

I'm not sure however that this would be more consitent with the other SDKs though. The java sdk equivalent of this change falls back to the env (well, actually a system property now... it's a long story...)

ref: https://github.com/aws/aws-sdk-java-v2/pull/6433/changes

Ditto with the node.js SDK https://github.com/aws/aws-sdk-js-v3/blob/a84cde64ab1985fbc1058f3188f82dd1b34428ce/packages-internal/middleware-recursion-detection/src/recursionDetectionMiddleware.ts#L38-L40