NB: Before opening a feature request against this repo, consider whether the feature should/could be implemented in the other OpenTelemetry client libraries. If so, please open an issue on opentelemetry-specification first.

Is your feature request related to a problem? Please describe.

The exporter transports are currently not particularly extensible. This isn't as true for gRPC given the JS implementation does support a bunch of environment variables, but for HTTP it's not possible to do something like support an HTTP proxy.

Describe the solution you'd like

Support providing an instance of http.Agent to the HTTP exporters. This would make it possible for vendors to support things like HTTP proxying with little to no extra complexity for SDK maintainers. We could either let the httpAgentOptions parameter also accept an agent instance, or add a new parameter.

The first option does require some kind of check to differentiate between agent options and agent instance. We can't use instanceof because the http module shouldn't be loaded before it's instrumented (in CJS). Node internally checks for an addRequest method which we could replicate. I don't have strong feelings either way.

Describe alternatives you've considered

This is motivated mostly by our need to support HTTP CONNECT proxying (which is already supported by gRPC), and I initially opened #5054 implementing it directly in the SDK. However this is a good chunk of code to maintain for something that hasn't really been requested much, and it wouldn't help with supporting

Additional context

The docs would need to mention that importing the http module to instantiate an agent before it is instrumented causes issues in CJS code. I was initially under the impression that this wasn't an issue for core modules (see #5220 (review)) but after playing with an example realized this is because our setup code is all ESM. cc @pichlermarc