Add embedded package to trace API

[MrAlias]

Similar to the metric embedded package, add one for the trace API exported interfaces.

This will, similarly, force SDK developers to make a choice on how they want unimplemented behavior to be handled.

[MrAlias]

The current no-op trace implementation lives in go.opentelemetry.io/otel/trace and is not fully exported. The only way to access it is via NewNoopTracerProvider which returns a trace.TracerProvider. This means a user will not be able to directly embed a no-op implementation with the current layout.

I'm working on a solution to this that will deprecate the NewNoopTracerProvider function in favor of an added go.opentelemetry.io/otel/trace/noop package. That package will contain an TracerProvider, Tracer, and Span no-op structs.

[MrAlias]

There is still an open question about the no-op package design in how the Tracer.Start method will work. Currently, the noop implementation matches the global default implementation in that it will propagate a span context for a non-zero context in a non-recording span (though, that span needs to explicitly be a nonRecordingSpan type currently which is likely not what the spec intended). However, given the spec only defines the default API behavior when no SDK is set (i.e. the default global implementation) to be this behavior I don't know if we should continue providing this in the noop package.

It should be easy enough for users who want this propagation behavior to wrap the noop implementation with one that does it.

[pellared]

Is this not related to the comment above #4027?

[MrAlias]

From SIG meeting:

• We want the default no-op behavior to propagate context for spans with span context
• If a user wants to disable this feature they can wrap the no-op implementation and disable it with method overrides of their own

[EdSchouten]

I had some code of mine where I used gomock to stub out implementations of TracerProvider/Tracer/Span. This now no longer works, because these interfaces contain private methods. The stubs that gomock generates obviously don't contain the private methods. Thanks.

[micronull]

@EdSchouten We have the same problem.