Fix encoding of OpenTracing span in AMQP messages

My understanding is that the current encoding of OpenTracing information in AMQP messages could cause some issues it is not compliant with the AMQP spec.

About annotations the spec says (http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-annotations):

The annotations type is a map where the keys are restricted to be of type symbol or of type ulong. All ulong keys, and all symbolic keys except those beginning with “x-” are reserved. Keys beginning with “x-opt-” MUST be ignored if not understood. On receiving an annotation key which is not understood, and which does not begin with “x-opt”, the receiving AMQP container MUST detach the link with a not-implemented error.

What seems to happen right now is that the MessageAnnotationsInjectAdapter is being used in combination with the TEXT_MAP format, which would directly inject uber-trace-id and uberctx-* into the message annotation map (see: io.jaegertracing.internal.propagation.TextMapCodec):

So it might happen, that a receiver simply closes this link when the annotation is present in the map.

The proposal would be to use something like x-opt-opentracing-trace-id and x-opt-opentracing-ctx- instead.

[calohmn]

In general I think it’s a good idea to keep an eye on the AMQP related work in https://github.com/w3c/trace-context/. There’s a draft in https://github.com/w3c/trace-context/pull/217 there. There it is proposed to use a binary format. As this doesn’t seem to be supported by Jaeger yet, I guess it’s premature to adopt it here. In any case I think it would be good to also address https://github.com/eclipse/hono/issues/1012 when doing changes on the Adapter classes here.

[ctron]

Looking into the code, it actually might be tricky to get the proposal implemented. Maybe a different way to do it would be to keep the current keys of uber-* but put them into the annotations under a single key, using an AMQP map.