Switch Jaeger remote sampler to "grpc" lite mechanism

[pavolloffay]

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

This is required for open-telemetry/opentelemetry-java-instrumentation#4898 (comment)

I am starting to work on this

[pavolloffay]

@anuraaga the remote sampler needs to get the response from the grpc service. So far the grpc lite mechanism is not parsing the response e.g. -

opentelemetry-java/exporters/otlp/common/src/main/java/io/opentelemetry/exporter/otlp/internal/grpc/GrpcExporter.java

Line 40 in a1a45d2

CompletableResultCode export(T exportRequest, int numItems);

Any preferences how it should be done? I have started by defining public interface GrpcService<REQ extends Marshaler, RES extends Marshaler> I don't have it working yet.

[anuraaga]

@pavolloffay GrpcExporter is an abstraction for exporting, but the actual stub is classes like these

https://github.com/open-telemetry/opentelemetry-java/blob/main/exporters/otlp/trace/src/main/java/io/opentelemetry/exporter/otlp/trace/MarshalerTraceServiceGrpc.java#L43

For the remote sampler, I don't think we need an additional abstraction, we should be able to use that type of class for the gRPC stub, and actually implement the RESPONSE_MARSHALER instead of returning a singleton.

[pavolloffay]

The issue is that we need logic from

opentelemetry-java/exporters/otlp/common/src/main/java/io/opentelemetry/exporter/otlp/internal/grpc/GrpcExporterUtil.java

Line 14 in a1a45d2

final class GrpcExporterUtil {

and {OkHttp,Default}GrpcExporterBuilder to make it all work.

an abstraction that would handle generic response type would be helpful.

[anuraaga]

I see - in that case the interface you mentioned does seem like a reasonable direction. I don't expect to need it outside the Jaeger sampler artifact though so if there is a solution that keeps things simpler without abstracting more than needed, we don't need to consider anything very general.

FWIW, I think we could consider making setChannel deprecated and a no-op, only having one implementation, unless we later got a complaint. I have a feeling in practice it's never used for the Jaeger sampler. But it is a bit risky, I would personally approve a PR that did that if you are up to it.