Shard aggregator lock

[carlosroman]

Updated version of #343 (fixes git conflicts)

---

This PR introduces optional sharding for client-side aggregation locks to significantly improve throughput in high-concurrency scenarios.

Problem:
The aggregator previously used a single sync.RWMutex for each metric type (counts, gauges, sets). Under high concurrency (many goroutines reporting metrics), this single lock became a major contention point, limiting throughput even when reporting unique metrics.

Solution:
We have introduced a sharding mechanism for these metric maps.

• The number of shards is configurable via a new option: WithAggregatorShardCount(int).
• The default shard count is 1, preserving the existing behavior and performance characteristics.
• When shardCount > 1, metrics are distributed across shards based on a hash of their context (name + tags), reducing lock contention by a factor roughly equal to the shard count.

Performance:
Micro-benchmarks demonstrate significant improvements in high-contention scenarios (M4 Max, 14 threads):

High Contention (Concurrent updates to unique metrics):

• 1 Shard: ~481 ns/op
• 32 Shards: ~78 ns/op
  -> ~6x throughput improvement

Overhead (Single thread, no contention):

• Legacy Implementation: ~31.46 ns/op
• New Implementation (1 Shard): ~31.47 ns/op
  -> Zero overhead introduced for the default configuration.

The optimization ensures that the hashing cost is completely bypassed when sharding is disabled (default), guaranteeing no regression for existing users.

[carlosroman]

Still need to investigate thread-safety of the sample() methods.

[carlosroman]

Calling sample() method is fine. Just tidied up the typos and comments on the PR.

[StephenWakely]

Looks good. Just a couple of very minor nits.

[StephenWakely]

This benchmark is mostly going to be benchmarking the string allocation here. We should instead preallocate a big list of these strings before b.ResetTimer().

[StephenWakely]

defaultTagCardinality isn't used anywhere, so should be removed.

It was removed in a previous PR because the value is now 0, but arguably it should be used and set in resolveOptions.

[carlosroman]

Thanks for picking that up. I forgot doing something with that value.

[StephenWakely]

I make this mistake every time too...

[StephenWakely]

Also this..

[StephenWakely]

Thinking about it, the defaultTagCardinality should be nil, we use nil to mean it hasn't been set here and should be loaded from the environment.

[StephenWakely]

🚀