[SDK] feat: exemplar filters

[proost]

Fixes #4178, #2526

Changes

Breaking Change is accompanied, But Because this is preview version, I think acceptable.

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

[codecov]

Codecov Report

❌ Patch coverage is 93.18182% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.29%. Comparing base (cf62199) to head (60b9440).

Files with missing lines	Patch %	Lines
...sdk/metrics/exemplar/filtered_exemplar_reservoir.h	88.89%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4267      +/-   ##
==========================================
+ Coverage   81.25%   81.29%   +0.05%     
==========================================
  Files         446      447       +1     
  Lines       18872    18891      +19     
==========================================
+ Hits        15332    15356      +24     
+ Misses       3540     3535       -5     

Files with missing lines	Coverage Δ
...ude/opentelemetry/sdk/metrics/exemplar/reservoir.h	100.00% <ø> (ø)
...entelemetry/sdk/metrics/exemplar/reservoir_utils.h	100.00% <100.00%> (ø)
...telemetry/sdk/metrics/state/async_metric_storage.h	95.24% <100.00%> (+4.33%)	⬆️
...ntelemetry/sdk/metrics/state/sync_metric_storage.h	90.00% <100.00%> (+6.25%)	⬆️
sdk/src/metrics/exemplar/reservoir.cc	75.00% <100.00%> (+8.34%)	⬆️
sdk/src/metrics/meter.cc	81.36% <ø> (ø)
...sdk/metrics/exemplar/filtered_exemplar_reservoir.h	88.89% <88.89%> (ø)

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lalitb]

@proost - I think this won't yet close #4178 - We can't declare exemplar stable till we have evaluated their performance on hot-path of metrics.

[lalitb]

For AlwaysOff, can we return GetNoExemplarReservoir() directly? Otherwise every metric recording still goes through the exemplar filter path just to drop the sample, so AlwaysOff is not really the same as disabling exemplar sampling

[proost]

For the performance, you are right. But according to spec, looks like current implementation is correct.

Here is what i understand:

ExemplarFilter decide whether measurement is eligible for the examplar. ExamplarReservoir decide wheter examplar to be stored or not.

If i missunderstand the spec, please let me know where I got it wrong. (spec is bit confused to me.)

[lalitb]

I think AlwaysOn still does not fully work here. This forwards the measurement, but the real reservoir drops it later if there is no valid span context. Since trace/span ids are optional for exemplars, AlwaysOn + Context{} should still produce an exemplar without trace ids. Can we add a test that collects from the real reservoir and checks the returned exemplar is non-null?

[proost]

Same point for the above #4267 (comment)