Sigv4 Authentication in OtlpHttp{Signal}Exporter

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is.
Context: AWS X-ray has released an Otel Native endpoint: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-OTLPEndpoint.html. However, this endpoint requires that the http requests be signed using sigv4: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html.

Situation: As of right now, trace senders are limited to using the otel collector (with Sigv4 extension) to send traces from their application to Xray otlp endpoint.

Is there a way to build a sigv4 extension for the java language SDKs so that applications can directly send to cloud otlp endpoint from the SDK? This essentially cuts an expensive middle man for faas environments like lambda. I was trying to look into this, but it doesnt look like the Java Otel SDK allows for http clients to be injected.

Describe the solution you'd like
A clear and concise description of what you want to happen.
I just need a mechanism to hook into the HTTP call workflow. Ideally in native HTTP clients these are interceptors (like the OkHTTP application interceptor here: https://square.github.io/okhttp/features/interceptors/#choosing-between-application-and-network-interceptors).

The interceptor would contain context about the HTTP request (body, params, headers, etc) and allow mutation of the HTTP request. I would then use the AWS SDK inside a custom interceptor to sign the HTTP request. I could also add this custom interceptor to the java-contrib repo and allow all otel/aws users to access this.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
I have considered the setHeaders() API and that does not solve the usecase since it does not have access to the HTTP request.

Alternatively, if we are allowed to inject in HTTP clients or specify that we would like to use an OkHTTP client (with our interceptor attached in) then we might be able to perform the signing.

Ideally, a separate OTLP exporter just for exporter to Amazon, would require alot of redundant code to maintain. I would assume other data storage vendors would also want some way to hook into the authentication process as well.

Additional context
Add any other context or screenshots about the feature request here.
Discussion with Jack over slack: https://cloud-native.slack.com/archives/C014L2KCTE3/p1734483601460489

Start by locating the Java SDK implementation of OtlpHttp{Signal}Exporter and how it creates its HTTP client. Review whether the exporter exposes request-level context or client injection, then compare that with the proposed interceptor and setHeaders() approaches. Done means a supported way to mutate or sign outgoing OTLP HTTP requests without maintaining a separate Amazon-specific exporter.