Add experimental FixedSizeRoundRobinReservoir

[dashpole]

This moves the implementation of the round-robin reservoir from #8257 to an experimental module.

This is an alternative approach to #7447, which had to be reverted in #8249 because of #8238. That approach attempted to make a highly-performant parallel version of algorithm-L, but ultimately is is very difficult to do so correctly.

Instead, this PR tries to improve parallel performance by sharding. Instead of one algorithm-L implementation for a k-sized reservoir, just have k algorithm-L copies for 1-sized reservoirs. This solves #8236 by moving the algorithm-L logic into the storage layer, so that each bucket is individually time-weighted. It also improves the concurrent performance of the fixed-size reservoir by reducing contention on the algorithm-L implementations, since they are distributed across multiple instances.

This should have identical runtime. One k-sized reservoir that handles n Observe calls has a runtime of O(k(1 + log(n/k)). A 1-sized reservoirs that handles n/k Observe calls (we have an even distribution because of our round-robin) would have O(1(1 + log(n/k)) runtime. k 1-sized reservoirs would have a O(k(1 + log(n/k)) runtime.

This has the following downsides:

• Increased size of the reservoir. It adds two integers and a float64, which might be significant if there are no dropped attributes.
• Bias from using round-robin.

This uses a simple round-robin strategy. This does introduce a bias. Algorithm-L by itself makes any combination of exemplars equally likely (e.g. the first k and last k are equally likely). Using round-robin makes some exemplar combinations impossible (e.g. the 1st and k+1 th). This would matter if there was periodic behavior that aligned with the reservoir size. I.e. there is something "special" about every kth Offer call. You would be highly likely to get only one "special" exemplar, and less likely to get zero or more than one special events. This tend to makes the results more "average". If this is a concern, I think this could be addressed with some added complexity, and some performance overhead.

TODO: Benchmarks.

Gemini helped me write this.

[codecov]

Codecov Report

❌ Patch coverage is 97.33333% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.0%. Comparing base (4086701) to head (605e516).

Files with missing lines	Patch %	Lines
sdk/metric/exemplar/x/reservoir.go	97.3%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #8305   +/-   ##
=====================================
  Coverage   82.9%   83.0%           
=====================================
  Files        314     315    +1     
  Lines      24985   25060   +75     
=====================================
+ Hits       20730   20804   +74     
  Misses      3882    3882           
- Partials     373     374    +1     

Files with missing lines	Coverage Δ
sdk/metric/exemplar/x/reservoir.go	97.3% <97.3%> (ø)

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

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

[dashpole]

Link failure is because the module isn't released yet.