Add composite propagator

[lalitb]

Fixes #541

Changes

Add composite propagator as per specs:
https://github.com/open-telemetry/opentelemetry-specification/blob/14d123c121b6caa53bffd011292c42a181c9ca26/specification/context/api-propagators.md#composite-propagator

For significant contributions please make sure you have completed the following items:

• CHANGELOG.md updated for non-trivial changes
• Unit tests have been added
• Changes in public API reviewed

[codecov]

Codecov Report

Merging #597 (59be748) into main (b8a08eb) will increase coverage by 0.05%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #597      +/-   ##
==========================================
+ Coverage   94.33%   94.39%   +0.05%     
==========================================
  Files         189      191       +2     
  Lines        8964     9023      +59     
==========================================
+ Hits         8456     8517      +61     
+ Misses        508      506       -2     

Impacted Files	Coverage Δ
...telemetry/trace/propagation/composite_propagator.h	100.00% <100.00%> (ø)
...est/trace/propagation/composite_propagator_test.cc	100.00% <100.00%> (ø)
sdk/include/opentelemetry/sdk/metrics/controller.h	96.66% <0.00%> (+6.66%)	⬆️

[seemk]

A few minor nitpicks:

• Should CompositePropagator own the propagators? i.e. use unique_ptr over shared_ptr?
• Pass by value and std::move?
• Would it help to add a method to add a propagator to composite propagator?

[lalitb]

• Should CompositePropagator own the propagators? i.e. use unique_ptr over shared_ptr?
• Pass by value and std::move?

Very valid points. I can't think of scenario where we need to share Propagator across. Will fix this, unless someone further comments with some scenario.

• Would it help to add a method to add a propagator to composite propagator?

This should help if we need to add propagator after creating the initial composite object. Specs ( https://github.com/open-telemetry/opentelemetry-specification/blob/14d123c121b6caa53bffd011292c42a181c9ca26/specification/context/api-propagators.md#composite-propagator ) doesn't ask for it explicitly so would keep it as it for now. We can add later if required.

[lalitb]

First two points are implemented now.

[seemk]

Are all of these includes needed or only some of them?

[lalitb]

Not all, will remove.

[lalitb]

done

[ThomsonTan]

Is it better to return nullptr here?

[lalitb]

This will need change across all propagators. We can do it separately if needed, not in current scope of this PR.

[ThomsonTan]

There seems no need to assign all intermediate extracted context to input context. Probably create temp context::Context to hold the extracted context and return the last one?

Is it possible to get empty propagators_ list, then return the input parameter context? Do we need initialize the context to empty in such case?

[lalitb]

There seems no need to assign all intermediate extracted context to input context. Probably create temp context::Context to hold the extracted context and return the last one?

Good point - I did implement this initially, but then later discovered that all other languages implementations are modifying the input context and so reverted. Specs doesn't say anything about it, so was unsure. Have changed it back as you suggested now. Let me know if you see any concerns here :)

Is it possible to get empty propagators_ list, then return the input parameter context? Do we need initialize the context to empty in such case?

Yes it's possible to get empty list, and we should be returning the input context unchanged it that case.