Add simple sharding in ValueMap to boost metrics update performance under stress.

[fraillt]

Idea is not new, it was tried in #1564, but implementation will be new :)

At the moment we have trackers: RwLock<HashMap<Vec<KeyValue>, Arc<A>>>, changing it to trackers: Vec<RwLock<HashMap<Vec<KeyValue>, Arc<A>>>>, is not enough, because attribute-sets supposed to be order agnostic, so we need to make sure that same attribute-set (even if key order is different) would use same tracker.
The idea is to have this structure instead:

            all_attribs: Vec<RwLock::new(HashMap::new())>,
            sorted_attribs: Mutex::new(HashMap::new()),

all_attribs will be sharded by attribute-set as it is, so updating it will be very fast, but for every new value we'll always need to insert into sorted_attribs. (All of this, except sharding part is implemented in #2288, and performance is mostly not affected, in addition it solves another issue as well #2093)

To implement actual sharding we need to a way to calculate shard index from attribute-set hash, so we need stable and preferably fast hashing function. #2296 deals with this issue.
Once both of these task are done, implement sharding becomes very straight forward.

I have tested this locally (by merging both tasks and implementing sharding on top), and results on 12 core CPU, with 24 shards, was ~5x improvement for stress test (metrics_histogram)
Throughput: 4,570,800 iterations/sec
vs
Throughput: 23,165,800 iterations/sec