Add embedded package to trace API

[MrAlias]

Resolve #4545
Resolve #4160

Similar to the metric API, add an embedded package for the trace API that includes types embedded in all API interfaces. This ensures implementers of the API will have to make a choice about their implementation's default behavior.

To ensure implementors have a noop options available to them for the default behavior, this also adds a trace/noop package with exported concrete No-Op types they can embed.

[codecov]

Codecov Report

Merging #4620 (725d34f) into main (da343ab) will increase coverage by 0.0%.
The diff coverage is 94.1%.

@@          Coverage Diff          @@
##            main   #4620   +/-   ##
=====================================
  Coverage   81.3%   81.3%           
=====================================
  Files        222     223    +1     
  Lines      17690   17721   +31     
=====================================
+ Hits       14393   14423   +30     
- Misses      2997    2998    +1     
  Partials     300     300           

Files	Coverage Δ
bridge/opentracing/bridge.go	63.7% <ø> (ø)
bridge/opentracing/provider.go	100.0% <ø> (ø)
bridge/opentracing/wrapper.go	100.0% <ø> (ø)
internal/global/trace.go	89.0% <ø> (ø)
sdk/trace/span.go	87.9% <ø> (ø)
sdk/trace/tracer.go	100.0% <ø> (ø)
trace/noop.go	61.9% <ø> (-4.8%)	⬇️
trace/noop/noop.go	100.0% <100.0%> (ø)
trace/trace.go	98.2% <ø> (ø)
bridge/opentracing/internal/mock.go	67.0% <0.0%> (ø)
... and 1 more

[pellared]

I think that this also solves #3277 as well as #4160

If you agree then I suggest updating the PR description.

[MrAlias]

I think that this also solves #3277 as well as #4160

If you agree then I suggest updating the PR description.

I think #4160 will be resolved by this. I can update the description. 👍

I don't know about #3277. That is a bug with the project's versioning policy. This doesn't change the versioning policy so I don't see it resolves that.

I also think #3277 should be closed, as the history shows. It is something we don't plan to change given the general OTel versioning policy.

[katiehockman]

@MrAlias do you have a planned date for when this change will be released? We have a PR ready that will make the necessary changes in our API implementation, but we'd like to be able to plan ahead to merge and release the changes as soon after the release as possible, to lessen the time our users could be impacted.

[MrAlias]

@MrAlias do you have a planned date for when this change will be released? We have a PR ready that will make the necessary changes in our API implementation, but we'd like to be able to plan ahead to merge and release the changes as soon after the release as possible, to lessen the time our users could be impacted.

@katiehockman we are waiting on two PRs to be merged before the next milestone is reached. I'm not really sure how long that will take given I would have guessed they would already have been merged at this point. I plan to discuss the two PRs there at the next SIG meeting, so hopefully we can get that release out in a week or two.

Should I ping you in the release prep PR for the next release? Or is there a better way to give you a heads up?

[katiehockman]

Should I ping you in the release prep PR for the next release?

Yep that works! Or just ping me here when you have a more finalized planned date of release. Thank you

[EdSchouten]

Why did #4545 get locked? Two people comment that this causes issues for them. Then without any response whatsoever it gets closed. That seem to be very inclusive to me.

[MrAlias]

Why did #4545 get locked? Two people comment that this causes issues for them. Then without any response whatsoever it gets closed. That seem to be very inclusive to me.

@EdSchouten if you have an issue to report please open a new issue. Do not comment on merged PRs. Comments such as these are treated as spam and will result in the discussion being locked.

[pellared]

@EdSchouten I responded in #4714. Please feel free to propose a better solution.