AWS SDK instrumentation: Leave HTTP attributes to HTTP instrumentations #8453

Is your feature request related to a problem? Please describe.
AWS SDK instrumentation creates unusual "off-spec" spans that combine HTTP and RPC/AWS SDK conventions. This makes the implementation awkward as the HTTP information is only available at a later point in the SDK request processing.

This was brought up in #8405 (comment) and #8405 (comment) (CC @mateuszrzeszutek).

You may consider implementing this in response to the recently merged major changes to HTTP conventions that would also require the AWS SDK instrumentations to support both old and new conventions with a switch (although this might be mostly possible through shared code in the HTTP instrumenter).

Describe the solution you'd like
AWS SDK instrumentation should not set any HTTP-related span attributes. Instead it should work together with the normal HTTP client instrumentations. An option to suppress child HTTP spans could be retained (I have no opinion on whether it should be on or off by default). Injection of the X-Ray header in the SDK HTTP request would still be done by the AWS SDK instrumentation, as it's an SDK-specific concern (see also additional context below).

It might be sensible to make an exception for the HTTP status code, as there is no generic response status capturing equivalent to the generic request capturing (rpc.method / rpc.service). Or maybe this is covered by exception reporting.

Describe alternatives you've considered
The AWS SDK could create a single nested HTTP child span itself. This would not allow us to follow the spec recommendations on tracking retries and redirects as separate spans but might be easy to implement.

Additional context
As per HTTP conventions, we should prefer to only create spans for the "physical" requests but not for the encompassing logical request, see https://github.com/open-telemetry/opentelemetry-specification/blob/216fb1938ebb71df68c51418fee5fb8af2e0d307/specification/trace/semantic_conventions/http.md#http-client
Specific AWS SDK conventions also don't mention this peculiar hybrid span convention, see https://github.com/open-telemetry/opentelemetry-specification/blob/216fb1938ebb71df68c51418fee5fb8af2e0d307/specification/trace/semantic_conventions/instrumentation/aws-sdk.md

There are special considerations for HTTP header injection. The AWS REST APIs can use hashing/signatures that include HTTP headers, so certain manipulations may cause requests to fail. #1837
In general it is not useful to inject into SDK HTTP requests (unless they go to some non-AWS endpoint, like an API-compatible re-implementation of a service that might support other means of context propagation). So the implementation will need to continue suppressing injection in the HTTP library implementing the call (but not span creation). See #1837 for more context on this. NB: I don't know this topic all to well. It is possible that simply checking if any header is already present in the HTTP request before setting it would resolve the concern of breaking the signature, or it might also break if adding certain known headers not present at time of signature creation.