Optimize postings offset table reading

[colega]

Instead of reading a generic-ish []string slice, we now always read two []byte slices: name and value. They point to the backing buffer slice until we store them as strings, where they're copied.

Moved the label-indices specific reading mechanism to that test only, since it's not being used anywhere else.

This avoids allocating a slice that escapes to the heap, making it both faster and more efficient in terms of memory management.

Also added a benchmark for a block with 1M series and 20 labels, which I think looks really promising:

name                 old time/op    new time/op    delta
OpenBlock/benchmark     130ms ± 3%      44ms ±10%  -66.47%  (p=0.008 n=5+5)

name                 old alloc/op   new alloc/op   delta
OpenBlock/benchmark    53.2MB ± 0%     5.7MB ± 0%  -89.21%  (p=0.008 n=5+5)

name                 old allocs/op  new allocs/op  delta
OpenBlock/benchmark     3.00M ± 0%     0.06M ± 0%  -97.91%  (p=0.008 n=5+5)

Old PR description: before applying feedback and optimizing even further

Instead of reading a generic-ish `[]string` slice, we can read a generic type which would be specifically `labels.Label` for the posting offset table.

This avoids allocating a slice that escapes to the heap, making it both faster and more efficient in terms of memory management.

Also added a benchmark for a block with 1M series and 20 labels, which I think looks really promising:

OpenBlock/benchmark     130ms ± 3%      85ms ± 3%  -35.10%  (p=0.008 n=5+5)

name                 old alloc/op   new alloc/op   delta
OpenBlock/benchmark    53.2MB ± 0%    21.2MB ± 0%  -60.10%  (p=0.008 n=5+5)

name                 old allocs/op  new allocs/op  delta
OpenBlock/benchmark     3.00M ± 0%     2.00M ± 0%  -33.33%  (p=0.000 n=5+4)

---

P.S.: is this the first generics usage in Prometheus?

[pracucci]

Makes sense to me

[bboreham]

It's very good, but I find it a little too clever.

Only two functions are passed as the read parameter to ReadOffsetTable - PostingsTableReader and reader. Since reader is only used in a test, suggest changing the test to work on labels, and hard-coding ReadOffsetTable to read Labels.

[bboreham]

PostingsRanges is never called?

[colega]

Apperently it's not. I can see it called in one Mimir's test though.

I feel we can remove it, also the Range type which is only used here, but I'd rather do that in a separate PR instead, leaving this one only for optimization changes.

[colega]

Thank you for your feedback, @bboreham, I applied it, also changing the way label & value are passed to the func: they're []byte now (as that reduces allocations of strings we don't want to store: compiler already optimizes map[string([]byte)] lookup to avoid an allocation).

Updated the benchmark in the description PTAL.

[bboreham]

LGTM.

I believe the code in TestIndexRW_Postings exists to check that Prometheus is writing LabelIndicesTable, so that it can be read by an older version of Prometheus.