statsd: improve worst-case latency for heavily contended aggregator

[nsrip-dd]

WIP - not ready for review, needs good benchmarks, I've overlooked an obvious race in the first version, etc...

The aggregator in the statsd package uses a sync.RWMutex to guard the count, gauge, and set maps. When a metric is udpated, the locking works like so:

• Take a read lock and check if the metric is there.
• If so, update the metric, release the read lock, and return
• Otherwise, release the read lock, take a write lock, create the metric, and add it to the map. Then release the lock and return.

It turns out that this pattern scales very poorly under heavy contention. We've seen >100ms latency in updating a metric at Datadog. We can see contention when lots of goroutines are creating new metrics, or when lots of goroutines race to create the same metric (the maps are regularly cleared.) See golang/go#76808 for more details.

This PR attempts to improve the worst-case latency by switching to sync.Map. According to the docs:

The Map type is optimized for two common use cases: (1) when the entry for a given key is only ever written once but read many times, as in caches that only grow, or (2) when multiple goroutines read, write, and overwrite entries for disjoint sets of keys.

I don't think either case exactly describes this library, but they're both kinda close. And in the linked GitHub issue, we've seen promising results switching to a sync.Map implementation similar to what this PR does.

This PR still needs a convincing benchmark. We'll also want to consider the overhead of wasted allocations if goroutines race to add a new metric. With this new implementation, the racing goroutines will all allocate a new metric and then add it to the map, but only the winner's allocation is actually used.