Instrument identity, registration conflicts, multi-callback registration, unregister support

[jmacd]

Fixes #2226
Part of #2232
Fixes #2250
Supercedes #2270
Related to, but does not supercede #2281
Part of #2280

Changes

See the discussion in #2226.
Defines "duplicate" and "identical" for Meter and Instrument concepts.
Permits duplicate instrument registration as a first-class feature, including the associated async callbacks
Clarifies that multi-instrument callback idioms are permitted.
Specifies support for unregistering async callbacks.
Specifies a warning for duplicate instrumentation registration conflicts (i.e., same name, not identical)
Specifies that SDKs are permitted to pass-through the semantic conflict.
Specifies that consumers are permitted to reject such data.

[jack-berg]

I think this is great 👍 👍

[pichlermarc]

LGTM with one nit. 🙂

[bogdandrutu]

@jmacd are we sure that this fixes #2232?

[jmacd]

@jmacd are we sure that this fixes #2232?

I tried to answer this here: #2232 (comment)

I changed the PR description to state this is part of #2232 either way, would prefer not to block on the answers to what I think are independent questions about supporting API-level deletion and/or a SDK-level memory preference.

[jmacd]

@bogdandrutu Do you think it's worth holding up this change for an answer to the question above? There are a number of approvals and the PR description has included "unregister support" from the beginning. It seems your question is whether adding unregister support is sufficient to address #2232, which we can debate, but do we still need to debate unregister support?

The original request in #2232 is for a way to Close an entire Meter, unregister its instruments and stop reporting its metrics. in the context of a metrics bridge. I've tried to frame this as request for unregistering callbacks and for allowing the SDK to automatically forget stale metrics.

@open-telemetry/specs-metrics-approvers Do we know of other reasons to support unregister()? I've tried to argue for this on the principle that without unregister support, users are forced to implement synchronization within callbacks on their own, which is not simple. (Unlike synchronous instruments, which are easy to stop using.)

[jmacd]

Yesterday I removed support for multi-instrument callbacks from this PR.
Here is the PR that will add the same after this PR merges:
#2355

[bogdandrutu]

@MadVikingGod

This change, specifically the relaxation of the callback at registration, allows us to better match the go ecosystem.

You still need to offer that.