Should we add GrpcSender (and SPI)?

[jack-berg]

In #5505 / #5533 we added a HttpSender abstraction and SPI interface for providing different implementations. A big motivator for this was to allow opentelemetry-exporter-otlp consumers to avoid the okhttp dependency, which can be problematic in certain applications.

#5557 provides an alternative implementation based on the jdk http client, which is great, but may not go far enough to solving the problem:opentelemetry-exporter-otlp bundles the grpc and http/protobuf variants of the OTLP exporters. The HttpSender / SPI solution remove the okhttp dependency for http/protobuf, but grpc still depends on okhttp.

Consumers can work around this by excluding "com.squareup.okhttp3:okhttp in maven / gradle, but then they must be careful to not use the grpc exporters.

A more elegant solution would be to:

• Provide a corresponding GrpcSender abstraction and SPI
• Rescope the new artifact opentelemetry-exporters-http-sender-okhttp to include both HttpSender and GrpcSender SPI implementations, and rename it to something generic like opentelemetry-exporter-sender-okhttp.
• Add a new artifact opentelemetry-exporters-grpc-sender-upstream containing the GrpcSender abstraction driven by the upstream grpc libraries.

We would then have to document that consumers of opentelemetry-exporter-otlp need to be aware:

• that the artifact contains both grpc and http/protobuf implementations
• by default, opentelemetry-exporters-sender-okhttp is included as a transitive dependency, and contains implementations of both
• if you want to opt out of okhttp, you need to add dependencies on at least one of opentelemetry-exporters-http-sender-jdk / opentelemetry-exporters-grpc-sender-upstream and be aware of the requirements of the exporter protocol you intend on using (grpc or http/protobuf)