Added AWS SDK Changes to support Bedrock spans and Application Signals

[AsakerMohd]

Changes

Added changes to detect bedrock spans and populate attributes accordingly. Also added logic to populate aws specific attributes used by AWS Application Signals like "aws.region", "aws.service", "aws.operation", "aws.requestId", etc. We are currently using our own fork of Opentelemetry-Instrumentation-AWS here: https://github.com/aws-observability/aws-otel-dotnet-instrumentation/tree/main/src/OpenTelemetry.Instrumentation.AWS. This change syncs our local fork so that we can stop relying on it and instead reference this directly instead.

I did some manual testing and was able to verify that the spans created contain the required information.

Pushing this PR for now to get some review going while we add some unit tests for the Bedrock related changes. Will add changes to CHANGELOG.md. No changes to public API.

Merge requirement checklist

• CONTRIBUTING guidelines followed (license requirements, nullable enabled, static analysis, etc.)
• Unit tests added/updated
• Appropriate CHANGELOG.md files updated for non-trivial changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.20%. Comparing base (71655ce) to head (8f09005).
Report is 678 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #2458       +/-   ##
===========================================
+ Coverage   73.91%   84.20%   +10.28%     
===========================================
  Files         267       34      -233     
  Lines        9615      747     -8868     
===========================================
- Hits         7107      629     -6478     
+ Misses       2508      118     -2390     

Files with missing lines	Coverage Δ
...rumentation.AWS/Implementation/AWSServiceHelper.cs	93.33% <ø> (-6.67%)	⬇️
...strumentation.AWS/Implementation/AWSServiceType.cs	71.42% <ø> (+4.76%)	⬆️
...on.AWS/Implementation/AWSTracingPipelineHandler.cs	87.17% <ø> (-0.58%)	⬇️

... and 271 files with indirect coverage changes

[AsakerMohd]

Not sure why the bedrock sem cov test is failing for v1.28. I didn't change how the sem covs are set there.

[ppittle]

catch (Exception ex)
        {
            Console.WriteLine("Exception: " + ex.Message);

I forget, is this standard practice for exception handling within this library? I'm fine swallowing parsing exceptions - but I don't recall if there is a preferred channel to let the user know there was a problem.

[AsakerMohd]

Actually i don't think there is any standard practice for handling exceptions in this specific lib. However, the standard convention throughout the contrib lib as whole is to use event sources like this for example: https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/55121760115c94e11571057f4263c43f4d71ad21/src/OpenTelemetry.Resources.AWS/AWSResourcesEventSource.cs. I'll add one for the Opentelemetry.Instrumentation.AWS

[ppittle]

This is defined in the semantic convention here: https://github.com/open-telemetry/semantic-conventions/blob/main/docs/gen-ai/gen-ai-spans.md?plain=1#L60

[ppittle]

Looking at the GenAI documentation page, it looks like the new GenAI attributes all existed prior to v1.27: https://github.com/open-telemetry/semantic-conventions/blob/v1.27.0/docs/gen-ai/gen-ai-spans.md

Is that correct?

[AsakerMohd]

Not sure if they existed prior to v1.27 but they're in v1.27 which means they fall into the legacy conventions.

[ppittle]

for the attributes that are not yet part of the Semantic Convention - I'm not sure if they should be added as "Legacy".

I'm also not sure if they should be added to an existing code page - ie it feels odd to add them to say v.1.29.0 when they aren't actually part of that spec either.

Any thoughts on this?

OR - it might be better to first send a PR to the Semantic Convention repo and get the attributes added - then they'll be part of a SemConv release and we wont have this problem. Given they're attributes are all in the AWS namespace I would expect the PR to be accepted rather quickly.