[otlp-exporter-base] come up with plan for implementing the `compression` option for browser exporters

[pichlermarc]

trafficstars

Description

The OpenTelemetry OTLP exporter spec REQUIRES us to implement a compression option for browser exporters:

The following configuration options MUST be available to configure the OTLP exporter. Each configuration option MUST be overridable by a signal specific option. [...]

• Compression: Compression key for supported compression types. Supported compression: gzip.
• Default: No value [3]
• Env vars: OTEL_EXPORTER_OTLP_COMPRESSION OTEL_EXPORTER_OTLP_TRACES_COMPRESSION OTEL_EXPORTER_OTLP_METRICS_COMPRESSION OTEL_EXPORTER_OTLP_LOGS_COMPRESSION
• Type: [Enum][] [...] [3]: If no compression value is explicitly specified, SIGs can default to the value they deem most useful among the supported options. This is especially important in the presence of technical constraints, e.g. directly sending telemetry data from mobile devices to backend servers.

Supported values for OTEL_EXPORTER_OTLP_*COMPRESSION options:

• none if compression is disabled.
• gzip is the only specified compression method for now.

Goal of this issue is to prototype a way to add compression when sending with either

• XHRTransport
• SendBeaconTransport - this may not be possible (a Content-Encoding header is required by most OTLP endpoints, communicating the compression via other mans may not be valid in OTLP).

The prototype solution should adhere to the following constraints:

• compression code should be tree-shakable, so that users that don't want to use compression don't have to include the compression code
• Ideally, look into hiding compression behind an interface that can be re-used across both Node.js and the Browser, see the node:http-based transport code here, so that the interface that is used is consistent across transports
• also consider how to do this with a potential fetch transport that follows the existing IExporterTransport interface.
• do not add it to the existing "legacy" exporter interface, for now we will introduce a new one that scales better and de-duplicates options (issue TBD)

Note that the prototype is not a production-ready implementation for this feature - the outcome of this issue is a draft PR to discuss the approach and another issue to implement what we have decided on.

This issue is considered done when

• [ ] a draft PR has been created proposing an approach
• [ ] a follow up issue has been created that documents the outcome of discussions and required steps to implement this feature, as well as any dependencies on other features that are needed first
• [ ] the aforementioned draft PR has been closed

Additional notes:

• implementation of this feature was previously attempted in #4493