Consider exposing OpenTracing-compatible gRPC API

[slimsag]

I haven't run very far with this idea, so this is just a thought dump for now. But I've been considering how Appdash could reach the most languages.. it stands to reason that we would gather support for a large number of languages by exposing a gRPC service which would literally be the OpenTracing API itself.

Then, from a user's perspective, they could either directly use this gRPC client from their language of choice OR we could even implement opentracing-python, opentracing-java, etc by simply calling out to this gRPC service.

This is interesting, because it could give many other tracers that do not wish to spend a significant amount of time implementing tracing clients in various languages automatic support if they were to expose the same OpenTracing-compatible gRPC service. This could also be done over, e.g. HTTP or others, I just chose gRPC because I am most familiar with it.

[bhs]

@slimsag c.f. go-kit/kit#247

[asilversempirical]

One thing to watch out for: https://github.com/sourcegraph/appdash/blob/master/internal/wire/collector.proto is a proto2 proto, and it's incompatible with proto3 without some changes. Namely: support for group fields was removed: https://github.com/google/protobuf/releases/tag/v3.0.0

This isn't a huge deal, except that there's no python3 support for proto2, only proto3. So doing this over gRPC exclusively doesn't open up python3 support.