feat(sdk-metrics)!: extract IMetricReader interface and use it over abstract class

[pichlermarc]

Which problem is this PR solving?

We periodically run into problems since private properties in classes cause the type to be incompatible between versions. This PR fixes that for MetricReader by extracting an interface which we then use instead of the abstract class type in our public interface.

In this PR MetricReader type stays as-is, but this is marked as a breaking change since we technically narrow down what's being provided by MeterProviderOptions.

Part of #5283

Type of change

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

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.54%. Comparing base (c00f36e) to head (ce19b91).
Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5311   +/-   ##
=======================================
  Coverage   94.54%   94.54%           
=======================================
  Files         318      318           
  Lines        8051     8051           
  Branches     1694     1694           
=======================================
  Hits         7612     7612           
  Misses        439      439           

Files with missing lines	Coverage Δ
...imental/packages/opentelemetry-sdk-node/src/sdk.ts	96.01% <100.00%> (ø)
packages/sdk-metrics/src/MeterProvider.ts	100.00% <ø> (ø)
packages/sdk-metrics/src/export/MetricReader.ts	100.00% <100.00%> (ø)
packages/sdk-metrics/src/state/MetricCollector.ts	100.00% <100.00%> (ø)

[legendecas]

this is marked as a breaking change since we technically narrow down what's being provided by MeterProviderOptions.

Isn't this change make the option bag more general to accept any object that conforms to the new interface, instead of a subclass? In this sense, it reads to me that this is not breaking.

[pichlermarc]

this is marked as a breaking change since we technically narrow down what's being provided by MeterProviderOptions.

Isn't this change make the option bag more general to accept any object that conforms to the new interface, instead of a subclass? In this sense, it reads to me that this is not breaking.

I'm not sure what the stability guarantees are for options bags like this. Practically this is non-breaking - and as a developer I would always expect this to become more general due to the context in which it should be used.

Technically however, the only way this can be breaking is that if someone else consumes a MeterProviderOptions object as part of their own code somewhere, and they expect a MetricReader instead of a IMetricReader. In that case the user that pulls in this change change will get a compile-time error.

[legendecas]

Thanks for the explanation!

[legendecas]

This has a conflict.