Have MeterContext::GetMeters return a copy instead of a span

[johanpel]

Fixes #1720

Changes

MeterContext::GetMeters returns a span viewing into the meters_ vector used to manage meter storage. While the span is constructed, the storage is locked, but when the span returns and the lock is released, another thread may modify the vector while the caller of MeterContext::GetMeters continues to work with the span.

This PR changes MeterContext::GetMeters to simply return a copy of the metrics storage vector while it is being locked.

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

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: johanpel / name: Johan Peltenburg (8635aa9)

[codecov]

Codecov Report

Merging #1777 (c4b04be) into main (d0571d8) will decrease coverage by 0.06%.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1777      +/-   ##
==========================================
- Coverage   85.79%   85.74%   -0.05%     
==========================================
  Files         171      171              
  Lines        5214     5214              
==========================================
- Hits         4473     4470       -3     
- Misses        741      744       +3     

Impacted Files	Coverage Δ
sdk/src/metrics/meter_context.cc	89.66% <100.00%> (ø)
ext/src/http/client/curl/http_client_curl.cc	80.31% <0.00%> (-1.13%)	⬇️

[lalitb]

Thanks for the PR @johanpel. Was thinking if we should instead change the storage container for Meters from vector to list, if that can avoid creating the copy during metric collection time. Something similar is done for storing multiple span processors here.

[lalitb]

@johanpel - I tried different approach to fix this issue in #1783 to avoid doing copy of meters. My concern is, even though we copy vector of shared_ptr, it can be still significant overhead for large number of meters as it is performed during hot path of collection. Let me know if you see any issues in that approach?

[lalitb]

Closing this as fix is delivered here #1783