Remove baggage handling from metrics SDK for now

[anuraaga]

Reading through the spec in context of #2150 to check it vs Java.

I think there should be a higher level cross-signal discussion about baggage before adding it to any particular signal. Notably, in Java instrumentation we generate one Attributes and would expect baggage to be populated into this via instrumentation. It would still be ok if the SDK in addition provided a mechanism for this transformation but would be awkward in two places, and the UX doesn't seem fleshed out vs the usage of baggage in traces and logs. I'm worried about jumping the gun on this.

The current restriction to synchronous instruments also seems to tie the behavior of the view to the usage within the API (the view doesn't really know if data comes from synchronous or not). This seems like an unexpected coupling.

Finally, it seems unclear what it means to get "extra dimensions" from Baggage/Context - baggage is clear, but context?

[reyang]

+1 with the consideration of:

1. the support for baggage can be an additive change post Stable
2. given the metrics effort has been running for long time, we should prioritize Stable with a confined scope instead of keep delaying with bigger scope

[jsuereth]

Just want to make two points:

1. I think baggage configuration/usage needs to be an SDK concern. While I agree instrumentation should provide seamless access to baggage, I'm not sure we want to remove signal-specific baggage controls. Especially in traces vs. metrics debates where metrics need to limit cardinality, it's HIGHLY likely that baggage will need first-class visibility, even if provided by instrumentation.
2. I agree the current written specification is vague enough for lots of interpretations. As long as APIs don't prevent context from being used in metric APIs, I think we can cut scope here and flesh this out better in the future.

Specifically, I think the View APIs allowing Context on measurements is critical for OpenTelemetry. For languages that allow/require explicit passing (Java [optional], Go [required], etc.) I don't want introducing context-derived values to be a breaking change later. Otherwise, we can defer the full baggage interaction for something better tuned for x-trace/x-logs/x-metrics.

[anuraaga]

The APIs need Context anyways for exemplars so I don't see them going away with the removal of language about baggage in SDKs. Adding to views in the future should be additive and no problem, agree that this is important so hopefully it will give some time to dig more into.

[reyang]

I'm trying to find a balance and I ended up with this proposal (which I brought up in the Oct. 29th, 2021 Maintainer's SIG meeting):

1. We mark the Metrics SDK Specification as Mixed Status, with MeterProvider/MetricReader/MetricExporter marked as Stable, and Baggage/Context/Exemplar as Experimental.
2. For metrics interaction with traces (e.g. exemplar) and context/baggage, we should focus on getting them to Stable in Dec. - early Jan. timeframe.

[jsuereth]

We decided in the last SiG meeting to be a little more aggressive and remove baggage-in-view support from the SDK specification. We'd like to take some time to investigate Baggage interaction w/ instrumentation libraries in both Trace + Metrics and see if this style configuration belongs in a different layer than the raw signal SDK.