Define MetricProducer as a third-party provider of metric data to MetricReaders

[dashpole]

Supersedes #2838 and #2722.

Issue: #1175

This is needed to support an OpenCensus metric bridge, which is will be proposed separately. It could also be used to support other bridges as well, such as a Prometheus bridge.

Changes

Define the MetricProducer interface, with one method: Produce(). MetricProducers SHOULD have a single InstrumentationScope, and can be configured with a Resource.

Add a RegisterProducer(metricProducer) function to MetricReader.

MetricProducers SHOULD allow configuration of temporality, but this isn't enforced via the metric reader. This is because the reader's temporality is configured as a function of OpenTelemetry instrument.

Changes from the previous iteration

• Integrate with the MetricReader instead of MeterProvider (Feedback from Add MetricProducer as a source of external metric data #2838 (comment))
• This no longer attempts to prevent duplicate Instrumentation Scopes, or limits a bridge to a single scope (it is still recommended to use a single scope).
• It now recommends that bridges allow configuration of the output temporality.

Things that are left up to implementations

• How the MetricReader handles multiple metric batches is NOT specified. SDKs are free to pass each metric batch to the exporter individually, or it may attempt to merge batches if, for example, the resource was the same between the batches. This also implies that any merge logic (e.g. handling duplicate instrumentation scopes) is also not specified, and is left up to the implementation.

@jsuereth @bogdandrutu @jmacd @reyang @pirgeo @MadVikingGod @MrAlias @jack-berg

[reyang]

Overall, I'm supportive - this is a critical part which makes it possible to converge OpenCensus.
I've left several non-blocking comments considering the added part is Experimental.

[jack-berg]

Non blocking comments!

[dashpole]

I've left several non-blocking comments considering the added part is Experimental.

Question i'm not entire sure of: I've marked the MetricBridge as experimental, but the Register() function is part of the MetricReader, which is stable. Does that make sense? Or would both essentially need to be stable for any stable languages to implement this?

[reyang]

I've left several non-blocking comments considering the added part is Experimental.

Question i'm not entire sure of: I've marked the MetricBridge as experimental, but the Register() function is part of the MetricReader, which is stable. Does that make sense? Or would both essentially need to be stable for any stable languages to implement this?

I feel it is clear to me. Maybe adding a note in the MetricReader.Register() section saying it is Experimental?

[dashpole]

I feel it is clear to me. Maybe adding a note in the MetricReader.Register() section saying it is Experimental?

Done.

[reyang]

LGTM assuming the changelog will be updated.

[dashpole]

LGTM assuming the changelog will be updated.

Added a changelog