Enhance B3Propagation to implement both formats on inject

[codefromthecrypt]

Right now, users choose B3Propagation or B3SinglePropagation for all trace instrumentation. Because messaging can have problems with multi-format, JMS ignores this and only writes b3 single, and Kafka has an option to override for the same reason. This is a proposal to make B3Propagation smart enough to default to the correct basic format for the kind of span.

What this changes

B3Propagation will write b3 multi for client spans and b3 single for producer/consumer spans by default. B3SinglePropagation will be deprecated.

What this improves

This removes special casing for messaging, which allows propagation add-ons such as secondary sampling to work there. It also allows someone to write both formats on client spans, something some proxies do when they don't know their downstream.

What this leaves unsolved

Other formats

There are other trace formats including grpc-trace-bin, x-cloud-trace-context, x-amzn-trace-id, and the currently developing traceparent formats. Solving for B3 doesn't solve for them, and some similar concerns will exist there.

Solving generically will result in a larger effort that may take more time than people have to offer now, and it isn't aligned with user demand. Right now, if we don't solve for B3, messaging just won't work with secondary sampling at all. Solving now for B3 doesn't stop us from making a generic solution later, ideally one that separates the primary trace format from secondary data such as extra fields or secondary sampling.

Runtime data

Looking solely at the kind of the span won't solve where there are framework specifics. For example, we have special-case code in grpc for their private format grpc-trace-bin. This solution can't read the type of request, and even if we had a type of request it would be unlikely that in the brave core abstraction, we would define gRPC.