AWS SDK v2.2 SPI Patch Migration

[anahatAWS]

Note: This is a continuation of #1111

Description of Changes

This implementation builds on the foundation established in PR #1111, transforming the structural setup into a fully functional SPI-based solution that will replace our current patching approach. This PR does not change the current ADOT functionality because patches have not been removed.

The next/final PR for v2.2 will remove the patches for aws-sdk-2.2 and have unit tests to ensure correct SPI functionality and behaviour. The final PR will also pass all the contract-tests once patches are removed.

Changes include:

• Migration of patched files into proper package structure:
  NOTE: We are not copying entire files from upstream. Instead, we only migrated the new components that were added by our patches and the methods that use these AWS-specific components. I deliberately removed any code that was untouched by our patches to avoid duplicating upstream instrumentation code. This selective migration ensures we maintain only our AWS-specific additions while letting OTel handle its base functionality.
  • AwsExperimentalAttributes - patch creates new class
  • AwsSdkRequest - patch on this otel file
  • AwsSdkRequestType - patch on this otel file
  • BedrockJsonParser - patch creates new class
  • FieldMapper - patch on this otel file
  • Serializer - patch on this otel file
  • BedrockJsonParserTest - patch creates new class
• Setup of dependent files directly copied from upstream aws-sdk:
  • MethodHandleFactory - copy-pasted from here
  • FieldMapping - copy-pasted from here
  • AwsJsonProtocolFactoryAccess - copy-pasted from here

These added files:

• Access and modify span attributes
• Provide consistent formatting tools for span attributes
• Can be updated at our convenience if needed

The classes we copied from upstream are just helper utilities that make it easier to inject span attributes during instrumentation. They're not core functionality that needs to stay in sync with upstream changes, rather standalone utilities that support our simpler, independent instrumentation without creating version lock-in. They're independent of OTel's core functionality, so we don't face the same version dependency issues we had with patching. We're just following upstream's structure for consistency.

OTel attribution for copied files

The 3 coped files have the OTel header included in them. This follows section 4 a)-c) in the ADOT LICENSE

Testing

• Existing functionality verified
• Contract tests passing
• Build successful

Related

• Skeleton PR for aws-sdk v2.2: Base of AWS SDK v2.2 SPI Implementation #1111
• Replaces patch: current patch

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[pxaws]

I think the following links are not correct. Could you double check?

===============================
AwsExperimentalAttributes - patch creates new class
AwsSdkRequest - patch on this otel file
AwsSdkRequestType - patch on this otel file
BedrockJsonParser - patch creates new class
FieldMapper - patch on this otel file
Serializer - patch on this otel file
BedrockJsonParserTest - patch creates new class
AbstractAws2ClientTest - patch on this otel file

[anahatAWS]

I have updated the links, should be correct now.

[pxaws]

Could you add comment to explain why this attribute is expected for a span created by upstream instrumentation? io.opentelemetry.javaagent.shaded.instrumentation.awssdk looks like a shaded class name. Will the name be stable in future?

[pxaws]

Any alternative way to check? It seems not very stable to rely on the shaded class name. It's quite easy for upstream to just use another name without knowing we are relying on the old name. The whole shading things should be transparent to business logic.

[anahatAWS]

addressed offline, will check the span attributes for aws-specific attributes that should be set by upstream aws-sdk. Span interface is designed for setting attributes, not reading them (Span API). It would have been more efficient if the api allowed us to search the map, but I think the approach I suggested is a way around it