feat: OpenTracing propagator

[mwear]

Which problem is this PR solving?

• This adds support for the semi-official OpenTracing (aka ot-tracer) header format.

Short description of the changes

• This PR introduces an OpenTracingPropagator that handles context propagation for the ot-tracer* headers.
• Supports propagation of both trace context and baggage context
• Note: a partial implementation exists in the Java Contrib repo: https://github.com/open-telemetry/opentelemetry-java/blob/master/extensions/trace-propagators/src/main/java/io/opentelemetry/extension/trace/propagation/OtTracerPropagator.java

[codecov]

Codecov Report

Merging #318 (72c4e07) into main (2319ae8) will increase coverage by 0.04%.
The diff coverage is 97.27%.

@@            Coverage Diff             @@
##             main     #318      +/-   ##
==========================================
+ Coverage   95.44%   95.48%   +0.04%     
==========================================
  Files         115      119       +4     
  Lines        6126     6273     +147     
  Branches      597      609      +12     
==========================================
+ Hits         5847     5990     +143     
- Misses        279      283       +4     

Impacted Files	Coverage Δ
.../opentelemetry-propagator-opentracing/.eslintrc.js	0.00% <0.00%> (ø)
...pentelemetry-propagator-opentracing/src/version.ts	0.00% <0.00%> (ø)
...ropagator-opentracing/src/OpenTracingPropagator.ts	95.83% <95.83%> (ø)
...tor-opentracing/test/OpenTracingPropagator.test.ts	100.00% <100.00%> (ø)

[dyladan]

The multi-header baggage breaks the fields usecase. Clearing fields out of an object won't work if we don't know all the fields that were used. Saving used fields might result in a memory leak. Not sure how to resolve this. It should at least be documented.

[mwear]

I added a comment further down above the fields() method.

[Flarna]

I think this should be also mentioned in readme similar as the restrictions regarding traceId which are already there.

[obecny]

can we do opposite then, keep the names of fields that should be there and clear all the rest that are not on that list?

[mwear]

I don't think that we actually use the fields method in the API or SDK, but it is there for users or instrumentation authors to use. I documented the special case on the readme. The specification seems to hint at this possibility as well:

Observe that some Propagators may define, besides the returned values, additional fields with variable names. To get a full list of fields for a specific carrier object, use the Keys operation.

From https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/context/api-propagators.md#fields

[obecny]

lgtm