Add proto3 encoding

[codefromthecrypt]

We should eventually map out a proto3 encoding even if this is just a direct translation from the json. We don't yet have an issue for this, but it is in response to #1644 and its parent.

In the mean time, we should at least make it possible in the java library to do this. Minimally, this requires adding zipkin2.codec.Encoding.PROTO3 to permit this format when using the async reporter.

[codefromthecrypt]

Looking at docs and generated code in proto3, I think the following are true for our key functions. Note that I'm assuming zipkin will use a field number less than 128 for the span data (StackDriver is field number 1, so yeah works for them too).

• int listSizeInBytes(int encodedSizeInBytes)
  The overhead is the field number then the size
  uint(field_number) + uint(encodedSizeInBytes)

• int listSizeInBytes(List<byte[]> values)
  The overhead is repeating above for each element (as messages can't be packed)

@basvanbeek this seem to gel with your understanding of proto3?

It looks like what the generated code does:

    size = 0;
    for (int i = 0; i < traces_.size(); i++) {
      size += com.google.protobuf.CodedOutputStream
        .computeMessageSize(1, traces_.get(i));
    }

https://developers.google.com/protocol-buffers/docs/encoding

[codefromthecrypt]

FYI @saturnism I will try to get this in by zipkin 2.6 which should land sometime in the next week or so depending on the UI-related changes that are still in flight. After that, it should be possible to make the zipkin-gcp sender using stackdriver-specific proto3 encoding even if we haven't defined a proto3 zipkin fomat yet

[jorgheymans]

will this eventually lead to zipkin starting as a grpc server ? or it's really just the protobuf encoding of the traces at this point ?

[codefromthecrypt]

will this eventually lead to zipkin starting as a grpc server ? or it's really just the protobuf encoding of the traces at this point ?

no. this is just data format. similar to how we handled thrift, to the degree we have core lib support for grpc, we'd do it in a zero dependency way. gRPC is a somewhat toxic dependency already, for example, if we packaged anything we'd have a wrestling match with zipkin-grpc for the version of boringssl + grpc etc. This is more about making the data format possible, and later defined.

[codefromthecrypt]

s/to the degree we have core lib support for grpc/to the degree we have core lib support for proto3/ sorry!