Verify compliant metric SDK specification implementation: MetricReader/MetricReader operations/RegisterProducer(metricProducer)

[MrAlias]

• Identify all the normative requirements, recommendations, and options the specification defines as comments to this issue
• Ensure the current metric SDK implementation is compliant with these normative requirements, recommendations, and options in those comments.

[damemi]

I'll work on this (since I took #3668 for MetricProducer too)

[damemi]

Requirements from the MetricReader RegisterProducer(metricProducer) section:

• RegisterProducer causes the MetricReader to use the provided MetricProducer as a source of aggregated metric data in subsequent invocations of Collect. RegisterProducer is expected to be called during initialization, but MAY be invoked later.

• Multiple registrations of the same MetricProducer MAY result in duplicate metric data being collected.

• If the MeterProvider is an instance of MetricProducer, this MAY be used to register the MeterProvider, but MUST NOT allow multiple MeterProviders to be registered with the same MetricReader.

---

The SDK implements periodicReader.RegisterProducer() and manualReader.RegisterProducer(). Both of which can be called at initialization or after.

There is nothing preventing multiple registrations of the same Producer. New registrations are simply appended to the in-memory list of Producers. In Collect(), all Producers will be called (including duplicates).

On the last point, MeterProvider in the SDK does not implement MetricProducer, but technically I think an SDK author could write a MeterProvider that does implement MetricProducer. In that case, our SDK's RegisterProducer() functions don't check if the metricProducer is a MeterProvider. This way, it's possible to register multiple MeterProviders to the same MetricReader (though we ensure only 1 is treated like a MeterProvider, they are all collected). We could enforce this stricter by checking if the producer implements a MeterProvider, and if so make sure that no sdkProducer is registered.

[MrAlias]

On the last point, MeterProvider in the SDK does not implement MetricProducer, but technically I think an SDK author could write a MeterProvider that does implement MetricProducer. In that case, our SDK's RegisterProducer() functions don't check if the metricProducer is a MeterProvider. This way, it's possible to register multiple MeterProviders to the same MetricReader (though we ensure only 1 is treated like a MeterProvider, they are all collected). We could enforce this stricter by checking if the producer implements a MeterProvider, and if so make sure that no sdkProducer is registered.

Yeah, I think the specification is a bit unclear on this, but I think that given our MeterProvider does not implement the MetricProducer interface the requirement that multiple of them cannot be registered does not apply. If a user decides to wrap our MeterProvider and create their own MeterProvider that does implement a MetricProducer it would follow that their implementation would need to make sure the restriction is followed.

I think we are compliant with the specification.

[MrAlias]

Closing as this looks done.