[otlp-exporter-base] refactor exporters to use a pluggable transport layer

[pichlermarc]

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

Currently, transport, configuration (options and environment variables) as well as serialization code are all mixed together in the OTLP exporters, making it increasingly hard to modify and test them. Further, a significant amount of logic and tests are duplicated across multiple OTLP exporters.

Describe the solution you'd like

This issue tracks refactoring the OTLP exporters so that the transport code is a pluggable component that takes a subset of the configuration passed to the exporter. This way we

• can test the behavior of the transport layer individually of the rest of the exporter
• in the future - may also allow users to pass their hand-rolled transport to the exporter
  • This is useful if the transport implementations provided by this repo are insufficient. One example would be providing polyfills for features that are not supported on browsers that have reached their EOL.

This transport component should not directly access any environment variables mixed in with other code as is currently done in the exporter. Determining its configuration should happen before instantiation; a finished configuration object should be passed to it.

Out of scope for this issue:

• Refactoring configuration code beyond what is necessary for the pluggable transport layer
• Refactoring serialization code beyond what is necessary for the pluggable transport layer
• Refactoring non-OTLP exporters to use this pluggable transport layer

Additional context

• The original proposal Create the transport layer and refactor exporters so that they can be used both in node and web #422 was written with Jaeger and Zipkin exporters in mind, but the Jaeger exporter has been deprecated and won't receive any feature updates. We may introduce the same pluggable transport to the Zipkin exporter in a follow-up.
• feat: introduce internal exporter http client #3577 attempted to introduce an internal http client for exporters but was closed before reaching the review state

[pichlermarc]

I'm working on this; I'm starting with otlp/http protobuf exporters first.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[pichlermarc]

This is in progress #4151 does change the gRPC exporters, a draft for http is available in #4415.

[pichlermarc]

This is work in progress. Here's a list of things that need to be done:

• refactor gRPC exporters (PR fix(exporter-*-otlp-grpc)!: lazy load gRPC #4432)
• refactor HTTP browser exporters (draft feat(exporter-metrics-otlp-proto)!: rewrite exporter #4415)
• refactor HTTP node.js exporters (draft feat(exporter-metrics-otlp-proto)!: rewrite exporter #4415)

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[pichlermarc]

This issue ended up with a super-large scope. The essential parts of this are complete, but we have not exposed most of it to the end-user. I'm considering spinning off an issue that tracks this explicitly.