[API] Remove Meters

[marcalff]

Fixes #2184

Changes

Changes:

• CMake: Add an experimental option, WITH_REMOVE_METER_PREVIEW.
• API: expose the new method MeterProvider::RemoveMeter().
• SDK: implementation for MeterProvider::RemoveMeter().
• Cleanup misc usage of the opentelemetry::v1 namespace, to make the implementation independent of the ABI version exposed.

For significant contributions please make sure you have completed the following items:

• CHANGELOG.md updated for non-trivial changes
• Unit tests have been added
• Changes in public API reviewed

[codecov]

Codecov Report

Merging #2205 (f7c5320) into main (8b61318) will decrease coverage by 0.18%.
The diff coverage is 0.00%.

❗ Current head f7c5320 differs from pull request most recent head c894d5b. Consider uploading reports for the commit c894d5b to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2205      +/-   ##
==========================================
- Coverage   87.49%   87.31%   -0.18%     
==========================================
  Files         169      169              
  Lines        4891     4900       +9     
==========================================
- Hits         4279     4278       -1     
- Misses        612      622      +10     

Impacted Files	Coverage Δ
api/include/opentelemetry/metrics/meter_provider.h	100.00% <ø> (ø)
api/include/opentelemetry/metrics/noop.h	37.26% <ø> (ø)
sdk/src/metrics/meter_context.cc	77.78% <0.00%> (-11.11%)	⬇️
sdk/src/metrics/meter_provider.cc	86.12% <ø> (ø)

... and 1 file with indirect coverage changes

[lalitb]

Thanks for the PR. Few questions before reviewing it :)

• Just curious why is this issue blocker for the shared libraries. Or do we mean it is a blocker for scenarios when applications dynamically load (dlopen()) and unload (dlclose()) shared libraries, and the Meter should be removed once the shared library is unloaded?

• Do we need to increment the ABI version for this change, as the new API is still not part of the specs (and mayn't be eventually)? Instead, as of now, we can introduce it under macro say - OPENTELEMETRY_REMOVE_METERS. Once this is part of the specification, we can increment ABI version for this.

• Looks like this PR is also introducing maintaining multiple ABI versions - maintaining all older versions would add complexity to the code, and need some discussion (refer - Prepare release, include fixes with abi breaking changes #1983 (comment)). As of now, should be keep it separate from this PR ?

[marcalff]

@lalitb

Thanks for the PR. Few questions before reviewing it :)

* Just curious why is this issue blocker for the shared libraries. Or do we mean it is a blocker for scenarios when applications dynamically load (dlopen()) and unload (dlclose()) shared libraries, and the Meter should be removed once the shared library is unloaded?

This is a blocker for scenarios when applications use dlopen() and dlclose() during normal operations (i.e., not just on the application startup and shutdown, but during the application workload).

Disclosure:

I happen to be instrumenting such an application, and in our case, the issue is so severe that we just can not use opentelemetry for metrics, at all, if this is not resolved.

The proper label can be either "blocking", or "priority:p0", no strong opinion here, as long as it gets addressed, hence the PR.

* Do we need to increment the ABI version for this change, as the new API is still not part of the specs (and mayn't be eventually)?  Instead, as of now, we can introduce it under macro say - OPENTELEMETRY_REMOVE_METERS. Once this is part of the specification, we can increment ABI version for this.

This is a two-fold question:

• RemoveMeter() is not part of ABI v1, so when this gets added to the ABI, it must be under ABI v2 in any case, as v1 can not change.
• This API is not (yet) part of the spec either, which raise the question if it will ever be there, and if so, if the spec will use the prototype proposed, or something similar but different. I agree that we need a feature flag to clearly identify apis that are not in the spec, to convey the notion that the api is experimental and subject to change, independently of the ABI version used.

* Looks like this PR is also introducing maintaining multiple ABI versions - maintaining all older versions would add complexity to the code, and need some discussion (refer - [Prepare release, include fixes with abi breaking changes #1983 (comment)](https://github.com/open-telemetry/opentelemetry-cpp/issues/1983#issuecomment-1440755915)). As of now, should be keep it separate from this PR ?

I will split this PR to keep only the fix itself, and move the ABI changes with #1983, for clarity, and to merge this PR sooner.

The discussion on ABI still needs to happen, as this is blocking many fixes, but sure, let's do that separately.

[marcalff]

Now ready for review.

[lalitb]

LGTM. Good to add a unit test. Also, should we enable this macro in the maintainers CI?

[esigo]

LGTM
Thanks :)

[marcalff]

LGTM. Good to add a unit test. Also, should we enable this macro in the maintainers CI?

Thanks for the review.

Added unit test, and coverage in maintainers CI.