When using the Zipkin tracer, the documentation currently indicates that five (B3) header properties need to be manually propagated by the application to enable end to end tracing to work.

In actual fact, regardless of whether using Zipkin or LightStep, the only header property that needs to be propagated is x-ot-span-context.

This doesn't prevent the application from using a tracer compatible with the B3 trace context format. The B3 headers are still passed into the application - and if the application makes use of those headers to (for example) create additional child spans, the updated B3 headers can be injected into any outbound request and will be used by the Egress proxy (once #1702 is merged).

Therefore I would propose that the documentation is updated to make this clear.

However it has also been suggested that the use of x-ot-span-context header, when Zipkin is the configured tracer, can now be removed - as the original reason for its use no longer applies.

It would be good to have some end user opinions on which direction is preferred:

1. Keep use of the single x-ot-span-context, and therefore application only has to manually propagate a single header for trace context

2. Remove use of x-ot-span-context when zipkin tracer is configured, and the application needs to propagate all 5 of the B3 header properties.