Move xray propagator from contrib (no history)

[martinkuba]

This is a second alternative to #4544. It adds the opentelemetry-propagator-aws-xray package from contrib without bringing over any history.

---

part of #4494

It should be possible to configure the xray propagator using the OTEL_PROPAGATORS env variable. This is currently documented here, and it is also part of the lambda spec.

[codecov]

Codecov Report

Merging #4603 (e20d992) into main (c046867) will increase coverage by 0.05%.
Report is 11 commits behind head on main.
The diff coverage is 100.00%.

❗ Current head e20d992 differs from pull request most recent head 30e6fce. Consider uploading reports for the commit 30e6fce to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4603      +/-   ##
==========================================
+ Coverage   92.83%   92.88%   +0.05%     
==========================================
  Files         329      329              
  Lines        9528     9604      +76     
  Branches     2053     2070      +17     
==========================================
+ Hits         8845     8921      +76     
  Misses        683      683              

Files	Coverage Δ
...kages/propagator-aws-xray/src/AWSXRayPropagator.ts	100.00% <100.00%> (ø)

... and 7 files with indirect coverage changes

[pichlermarc]

Looks good 👍 We may need to add/remove some devDependencies (edit: for the changelog, we could mention that it has moved over, and that versions 1.4 through 1.22 have been skipped)

Note to reviewers: this package is already stable in contrib, so we can only make minimal changes to it.

[martinkuba]

... for the changelog, we could mention that it has moved over, and that versions 1.4 through 1.22 have been skipped

I have added this as a feature to changelog. Let me know if you want to classify it differently. And I have added a note in the README of the package about the skipped versions.

[weyert]

Does that mean we could move Google Trace to here too? Would be nice to be able to configure that too

[pichlermarc]

Does that mean we could move Google Trace to here too? Would be nice to be able to configure that too

No. It's not a well-known propagator according to the specification.

[pichlermarc]

@martinkuba tests are likely failing due to a different version of @grpc/gprc-js being pulled in.
I'll push some changes to package-lock.json to this PR in a moment that should resolve the build issues.

We'll need to update @grpc/grpc-js and the tests for the exporters in another PR (#4620)

[trentm]

LGTM, with a nit in the rEADME.

[trentm]

That link is no longer valid: both the relative path, and there is no "Stable" section in the CONTRIBUTING.md in the core repo.

As well, there is no component_owners.yml in this repo.

Perhaps drop this "## Status" section? Not sure.

[anuraags]

Is there any movement happening on this? Would like to be able to use an official xray propagator in my services.

[pichlermarc]

Is there any movement happening on this? Would like to be able to use an official xray propagator in my services.

It will be included in the next release 1.24.0.

[Flarna]

Would like to be able to use an official xray propagator in my services

I don't think it's more official than now just because the repo changes.

[martinkuba]

@anuraags You can use the xray propagator now - the lambda instrumentation uses it automatically as well as the lambda layer. You can also configure it manually in the TracerProvider. This change will only make it possible to set the propagator via the env variable.

[weyert]

Does that mean we could move Google Trace to here too? Would be nice to be able to configure that too

No. It's not a well-known propagator according to the specification.

Curious why only one of the major Cloud providers gets special treatment within the OpenTelemetry specification

[Flarna]

I guess it's up to other cloud providers (or their users) to create PRs in OTel spec repo to get their special thingies in.

[martinkuba]

@weyert It's based on the list of known values for the OTEL_PROPAGATORS env variable defined here. But I don't think there is anything preventing us from adding others.

And as a side note, the intent of this effort is to actually move the xray propagation from lambda instrumentations to the global configuration (via the env var), as having it hard-coded gave x-ray special treatment.