Move SpanKey to internal package

[mateuszrzeszutek]

This is probably a class that we don't want to expose in instrumentation-api's public API.

[mateuszrzeszutek]

For the record: this PR will break the bridging with the previous instrumentation-api versions; but since it's still alpha maybe breaking changes are okay.

[trask]

@lmolkova does this cause any issues for your use case(s)?

[lmolkova]

@trask thanks for the heads up! I can work around it.

I have a small concern around it: assuming I don't use instrumentation-api to instrument my library (which is not a hard requirement), I won't be able to register my spans and suppress auto-instrumented ones. It's just an extra limitation.

I also understand that public API is a big pain and if making it internal can get instrumentation-api closer to stability, it's probably more important. And once (if) layering and suppression lands in the cross-language spec, we'll expose it back in some way.

[lmolkova]

And more to

I don't use instrumentation-api to instrument my library

if my understanding is correct, instrumentation-api is a super-useful convenience layer, but it probably has limitations compared to the direct usage of tracing and metrics APIs. If I want to go low lever and use them directly, I'd still need all the knobs to control everything that instrumentation-api can control.
I.e. hiding all the APIs to control and interact with instrumentation-api is not a great long-term approach (but maybe a good short term solution)

[iNikem]

I want to remind you that spec explicitly discourages direct access to context keys:

It is recommended that concerns mediate data access via an API, rather than provide direct public access to their keys.

Also in context Trace API:

API users SHOULD NOT have access to the Context Key used by the Tracing API implementation.

I think this recommendation is applicable here as well

[lmolkova]

@iNikem SpanKey and its instances is not a ContextKey, it's an API that hides one.

[trask]

And once (if) layering and suppression lands in the cross-language spec, we'll expose it back in some way.

👍