Separate context propagation (OTEP 66)

[dyladan]

This PR is absolutely massive. Sorry about that but there was no real great way to split it up and still have it build/pass tests

Fixes #773

Which problem is this PR solving?

• Introduce a context mechanism which stores things like active span (will store correlations in the future)

OTEP 66: https://github.com/open-telemetry/oteps/blob/master/text/0066-separate-context-propagation.md
Spec: open-telemetry/opentelemetry-specification#424

Short description of the changes

API

• API now depends on Scope Base which contains the context class (explanation below).
• Update propagators interface to accept Context

Scope Managers

• In the future these will need to be renamed to Context Managers (probably)
• Scope managers now store Context instead of directly storing a span
• Scope base contains the Context class
• Scope managers now return the ROOT_CONTEXT when they would otherwise return null (disabled, no active scope, etc)

Core

• Add a Context helper class with getters/setters for the context object

Propagators (core and jaeger)

• Update to use new Context based interface

Plugins

• Update to use new Context based propagators interface

[codecov-io]

Codecov Report

Merging #769 into master will decrease coverage by 0.54%.
The diff coverage is 96.19%.

@@            Coverage Diff             @@
##           master     #769      +/-   ##
==========================================
- Coverage   92.93%   92.39%   -0.55%     
==========================================
  Files         233      239       +6     
  Lines       10545    12621    +2076     
  Branches     1028     1128     +100     
==========================================
+ Hits         9800    11661    +1861     
- Misses        745      960     +215

Impacted Files	Coverage Δ
...emetry-exporter-prometheus/test/prometheus.test.ts	98.66% <ø> (+0.05%)	⬆️
packages/opentelemetry-metrics/src/types.ts	100% <ø> (ø)
...kages/opentelemetry-metrics/test/mocks/Exporter.ts	33.33% <ø> (-66.67%)	⬇️
packages/opentelemetry-metrics/src/Meter.ts	100% <100%> (+1.4%)	⬆️
...-metrics/test/export/ConsoleMetricExporter.test.ts	100% <100%> (ø)	⬆️
packages/opentelemetry-metrics/src/Metric.ts	85.18% <100%> (-0.97%)	⬇️
...pentelemetry-exporter-prometheus/src/prometheus.ts	92.07% <100%> (+0.07%)	⬆️
...ckages/opentelemetry-metrics/src/export/Batcher.ts	100% <100%> (ø)
packages/opentelemetry-metrics/test/Meter.test.ts	100% <100%> (ø)	⬆️
...ges/opentelemetry-metrics/src/export/Aggregator.ts	100% <100%> (ø)
... and 145 more

[dyladan]

API now depends on scope base because that is where context is. Context is a separate mechanism outside of the API and the SDK, but which is depended on by both.

[Flarna]

Maybe Context and the dummy implementation should be moved like it was done with a other parts recently?

[dyladan]

I would be willing to move Context into it's own package. @mayurkale22 wdyt?

[mayurkale22]

Still thinking on this, I will also check how other libraries are doing it.

[vmarchaud]

When we started it we decided to move it back so it could be used by other projects. However since it's started to get heavily linked to the OT specs (and not storing generic context) i would be in favor to move it

[dyladan]

@vmarchaud I'm sorry I don't understand, you would be in favor of context having it's own package or you would be in favor of moving it into core/api/other?

[mayurkale22]

In order to keep PR short (off the top of head):

• Keep DistributedContext related changes separate from this PR (AFAIK DistributedContext name changed to CorrelationContext but all other semantics are as it is).
• format and Carrier enhancement can be decoupled from this one - at first glance, seems straightforward and easy to merge.
• Maybe another PR just to add Context class.

WDYT?

[mayurkale22]

btw, this is great work 💯

[dyladan]

@open-telemetry/javascript-approvers I know this is a big change but I would appreciate some reviews here please

[bg451]

okay I did a quick pass and everything looks 👍

[vmarchaud]

Looks good to me. i think we can merge as-is and do refactor (like renaming to context-manager or moving the noop/interfaces inside API) on follow-up PR

[dyladan]

Looks good to me. i think we can merge as-is and do refactor (like renaming to context-manager or moving the noop/interfaces inside API) on follow-up PR

I agree except that noop implementations won't ever be in the API in this case. Context is meant to be a standalone concept that the api and sdk both consume.

[vmarchaud]

@dyladan Indeed, i mixed things ^^

[OlivierAlbertini]

LGTM

[mayurkale22]

lgtm