Add basic stress testing framework + counter.add test

[lzchen]

Discussed in the weekly Rust SIG, creates a stress testing framework under the folder stress to test throughput of functions in our API.

Measures the amount of times a certain function is called within a sliding window (2 seconds, can be configured in the future) to using the max number of cpus available.

Note this provides basic functionality and only prints to the console.
Sample output:

Throughput: 412998.00 requests/sec
Throughput: 404226.00 requests/sec
Throughput: 417000.00 requests/sec
Throughput: 403440.00 requests/sec
Throughput: 395148.00 requests/sec
Throughput: 404172.00 requests/sec
Throughput: 395412.00 requests/sec
Throughput: 400740.00 requests/sec
Throughput: 390132.00 requests/sec
Total requests processed: 7418976

[codecov]

Codecov Report

Patch coverage: 2.2% and project coverage change: -0.2 ⚠️

Comparison is base (f42c11d) 55.1% compared to head (d7db365) 54.9%.

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #1045     +/-   ##
=======================================
- Coverage   55.1%   54.9%   -0.2%     
=======================================
  Files        149     151      +2     
  Lines      18143   18242     +99     
=======================================
+ Hits       10006   10025     +19     
- Misses      8137    8217     +80     

Impacted Files	Coverage Δ
stress/src/throughput.rs	0.0% <0.0%> (ø)
stress/src/metrics.rs	14.2% <14.2%> (ø)

... and 20 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[jtescher]

Running this locally looks like most of the time is spent waiting on the mutex contention when aggregating, we could consider more optimized methods for updating those sums. e.g. I can get more than 2x the current throughput by switching to a SkipMap for the sum's value map so there is likely quite a bit of headroom here.

Also the conversion into attribute sets will quickly become a bottleneck too once a test is added for that case, so we may want to consider an API change that allows the attribute sets to be precomputed.

[cijothomas]

looks good start. we can iterate this in follow ups.

[lzchen]

@jtescher

Running this locally looks like most of the time is spent waiting on the mutex contention when aggregating, we could consider more optimized methods for updating those sums. e.g. I can get more than 2x the current throughput by switching to a SkipMap for the sum's value map so there is likely quite a bit of headroom here.

I was not able to get any improvements when trying out SkipMap, perhaps I implemented it incorrectly. Could you maybe paste your code/submit a pr for an improvement on the current implementation?