Support compression in OTel sources (trace, logs, metrics)

[tmarszal]

Is your feature request related to a problem? Please describe.
By default, OpenTelemetry Collector compress its requests body (along with Content-Encoding header). Otel-trace-source is not supporting this (responding with INTERNAL: Invalid protobuf byte sequence) and it needs to be turned off in the OpenTelemetry Collector configuration.

Describe the solution you'd like
Data Prepper should accept Content-Encoding header and adjust to it.

Describe alternatives you've considered (Optional)
Alternatively, it can let users configure which compression they intend to use, however it requires coordinated changes on both Collector and Prepper, so following HTTP header guidance is preferable.

Additional context
Found while reporting #1152

[dlvenable]

Thank you for making this feature request. This is a valuable feature especially since the OTel Collector is using compression by default.

We need to determine if our current Armeria version supports compression or if we need to update. We are currently blocked on updating Armera per #924 .

[chenqi0805]

There is probably no out-of-the-box protobuf compression supported in Armeria: https://javadoc.io/doc/com.linecorp.armeria/armeria-javadoc/latest/com/linecorp/armeria/server/grpc/GrpcServiceBuilder.html#enableUnframedRequests(boolean). Will confirm with their community.

[chenqi0805]

From community help, EncodingService might help resolve the issue:

sb.service(grpcServiceBuilder.build(), EncodingService.newDecorator());

[dlvenable]

Thanks @chenqi0805 for looking into this. It does appear that this class is in Armeria 1.9.2 which are currently on. So this might be something we can do even without updating Armeria (though we still should do that).

[chenqi0805]

Actually DecodingService is what we need. Right now it only supports gzip decoding and does not require armeria upgrade.

[dlvenable]

Please support in all three sources:

• otel_trace_source
• otel_logs_source
• otel_metrics_source