[mheffner]

Problem

--otlp-exporter-compression none had no effect. The OTLP exporter always gzipped request bodies and sent grpc-encoding: gzip or Content-Encoding: gzip.

The exporter config stored compression as Option<CompressionEncoding>, but the CLI value is the enum CompressionEncoding { Gzip, None }. .into() converted CompressionEncoding::None into Some(CompressionEncoding::None), and the request path only checked compression.is_some(), so "none" still enabled gzip.

Fix

• The OTLP exporter config and request code now hold a plain CompressionEncoding (default Gzip) instead of an Option.
• The is_some() checks for the gRPC header, the HTTP header and body encoding are now explicit checks for CompressionEncoding::Gzip.
• The CLI value is passed straight through to with_compression_encoding.
• The per-signal overrides (--otlp-exporter-{traces,metrics,logs}-compression) stay Option, where unset means "inherit the base setting."
• CompressionEncoding now derives PartialEq.

Kafka, ClickHouse and Parquet already use plain enums, so they don't have this bug.

Breaking change

OTLPExporterConfig::with_compression_encoding now takes CompressionEncoding instead of Option<CompressionEncoding>. External callers passing Some(x) should pass x, and callers passing None should pass CompressionEncoding::None.

Testing

• New unit tests check that none produces no compression and no gzip headers, and gzip produces both, over gRPC and HTTP.
• A new test covers a per-signal override against inheriting the base setting.
• cargo fmt is clean, and cargo test passes.
• cargo clippy --all-targets adds no new warnings. It already fails on main because of an existing bench config_builder arity error.
• In benchmarks, compression none now uses about 51% less CPU per span than the old gzip behavior.