Generator performance

[mdisibio]

What this PR does:
Metrics generator span metrics and service graphs are very popular, but memory usage can be quite high for high-cardinality setups, for example 1+ million active series in a single pod. I noticed some areas for improvement to reduce memory.

This PR contains 2 updates:

(1) on the surface it updates histograms to pre-compute all prometheus labels during creation, instead of during collection time. This way we alloc the labels once instead of on every scrape. This is possible because all of the labels for a specific histogram bucket are fixed, even external labels which are configured via runtime config.

(2) Almost more importantly in mind, it's adding a suite of benchmarks for the generator, which include WAL and non-mock registry. These benchmarks will help us identify more improvements like (1). Skimming through the module I've left several TODOs large and small of next areas to update.

Benchmarks show a large reduction in mem in Collect. Tested this in an internal cluster and it was ~15% total working set savings.

          │  before.txt  │              after.txt              │
          │    sec/op    │    sec/op     vs base               │
PushSpans   1.421m ±  1%   1.441m ±  1%   +1.36% (p=0.002 n=6)
Collect     31.30µ ± 13%   10.34µ ± 14%  -66.96% (p=0.002 n=6)
geomean     210.9µ         122.1µ        -42.13%

          │ before.txt  │             after.txt             │
          │ heap_in_use │ heap_in_use  vs base              │
PushSpans   15.69M ± 1%   15.50M ± 0%  -1.20% (p=0.002 n=6)
Collect     15.68M ± 0%   15.49M ± 0%  -1.20% (p=0.002 n=6)
geomean     15.68M        15.50M       -1.20%

          │  before.txt   │              after.txt              │
          │     B/op      │     B/op      vs base               │
PushSpans   705.8Ki ±  0%   705.9Ki ± 0%        ~ (p=0.310 n=6)
Collect     31.27Ki ± 11%   14.47Ki ± 4%  -53.73% (p=0.002 n=6)
geomean     148.6Ki         101.1Ki       -31.98%

          │  before.txt  │              after.txt              │
          │  allocs/op   │  allocs/op    vs base               │
PushSpans   18.58k ±  0%   18.58k ±  0%        ~ (p=1.000 n=6)
Collect      71.00 ± 11%    21.00 ± 14%  -70.42% (p=0.002 n=6)
geomean     1.149k          624.7        -45.61%

Which issue(s) this PR fixes:
Fixes #

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[zalegrala]

Looks good. I appreciate the TODOs also.

[zalegrala]

I love the full stack benchmark. This is something we might want to do for other components as well.

[zalegrala]

Why force a GC after the benchmark has been timed? Is this to avoid impact on later benchmarks, or to get accurate memory summary below?

[mdisibio]

In this case I was trying to see if the benchmarks could help measure inuse memory, so it is recording HeapInUse at the bottom. Without the GC it just keeps growing in between runs of the benchmark (-count=5 for example). So this was an attempt to make the inuse metric more useful.