perf(approx_topk): Reduce memory usage of HyperLogLog in approx_topk.

[jeschkies]

What this PR does / why we need it:

The count min sketch data structure backing the new approx_topk aggregation uses HyperLogLog (HLL) to track the actual cardinality of the aggregated vector.

We were using the sparse version of the HLL. However, that would result in a memory and allocation overhead.

                               │ before.log  │              after.log              │
                               │   sec/op    │   sec/op     vs base                │
HeapCountMinSketchVectorAdd-16   425.4m ± 2%   357.7m ± 3%  -15.91% (p=0.000 n=10)

                               │  before.log   │              after.log               │
                               │     B/op      │     B/op      vs base                │
HeapCountMinSketchVectorAdd-16   12.098Mi ± 0%   2.627Mi ± 0%  -78.29% (p=0.000 n=10)

                               │ before.log  │             after.log              │
                               │  allocs/op  │  allocs/op   vs base               │
HeapCountMinSketchVectorAdd-16   116.9k ± 0%   108.8k ± 0%  -6.92% (p=0.000 n=10)

Special notes for your reviewer:

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• Documentation added
• Tests updated
• Title matches the required conventional commits format, see here
  • Note that Promtail is considered to be feature complete, and future development for logs collection will be in Grafana Alloy. As such, feat PRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior.
• Changes that require user attention or interaction to upgrade are documented in docs/sources/setup/upgrade/_index.md
• If the change is deprecating or removing a configuration option, update the deprecated-config.yaml and deleted-config.yaml files respectively in the tools/deprecated-config-checker directory. Example PR

[jeschkies]

The overall performance is only improved slightly. See https://raintank-corp.slack.com/archives/C029V4SSS9L/p1735567230600989?thread_ts=1734692230.148749&cid=C029V4SSS9L

[chaudum]

LGTM

[chaudum]

Line can be removed

[cstyan]

I think we should leave a comment.

// Sparse HLL sketches should result in less memory usage for cardinalities of 100k or less but the automatic transition from sparse
// to non-sparse sketches above that cardinality range results in significantly more memory allocs/bytes. 
// Until we have a reliable way of estimating the cardinality set in advance, always use non-sparse for faster performance.

[cstyan]

good to know that the auto transition in the HLL library is this expensive 👍