feat(api): Add delegating no-op meter provider

[hectorhdzg]

Fixes #3622

Short description of the changes

Adding ProxyMeterProvider and ProxyMeter

Type of change

Please delete options that are not relevant.

• Breaking change (fix or feature that would cause existing functionality to not work as expected)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Unit tests

Checklist:

• Followed the style guidelines of this project
• Unit tests have been added

[JacksonWeber]

LGTM

[maryliag]

Hey Hector, you marked this as "Breaking change", would you mind providing more info on that?
Also, you still have the template part of "How Has This Been Tested?" on your PR description, you might want to update that 😄

[hectorhdzg]

@maryliag sure thing, this is a breaking change because the behavior of metrics.getMeterProvider would be different now, it will return a ProxyMeterProvider instead of the actual registered meter provider, same as current behavior for tracerProvider

[pichlermarc]

Thanks for working on this. 🙂 I think for this to be feasible we also need the instruments to be proxies. 🤔

[pichlermarc]

There's a certain difficulty in the case of the metrics API vs the trace/logs APIs - there's another layer that needs to be taken into account, which is the instruments.

In Traces, the (no-op) span is an object which is only kept for the time that the span is active. So one span being no-op is not too problematic. For logs, the record is passed straight to the logger so it's also not a problem there. In metrics however, an instrument is instantiated early and is kept over the lifetime of the app. That means that when a user gets a Meter, they usually also create the Instruments already. A later-updated ProxyMeter would therefore be of very limited help as the instruments would also need to be proxies in order to give a smooth experience.

[hectorhdzg]

Thanks for taking a look @pichlermarc, I wanted to fix #4112, so this is still relevant for us, I understand this change may need a major version update in the api package, maybe this is something I can move to a different branch and start experimenting with Instruments proxies or similar concept, what do you think?

[pichlermarc]

I don't think the major bump is necessary for this (just as with logs and traces). The types we export from the API are what we guarantee will be there. If there's extra properties on the registered SDK and those are available on the API too in plain JavaScript, then that was never guaranteed to also be there when returned by the API.

We can merge this to a separate branch to experiment with delegating instruments, but I think that could also be done here on this branch, as the PR won't really address the whole problem (instruments created before SDK registration being no-op) as it stands right now.