fix: Use a pool of LabelPairs to reduce memory allocs

[bryanhuhta]

We see pretty heavy memory usage when querier.v1.QueryService/Series calls are made on blocks with large a index.tsdb. For a real world example, see here.

In this flamegraph, a ~7.7mb index.tsdb file is being used, resulting in using ~680mb of memory.

The culprit is this loop in getUniqueLabelsSets:

pyroscope/pkg/phlaredb/block_querier.go

Lines 1992 to 2006 in e1a13ca

	for postings.Next() {
	matchedLabels := make(phlaremodel.Labels, 0, len(names))
	for _, name := range names {
	value, err := b.index.LabelValueFor(postings.At(), name)
	if err != nil {
	if err == storage.ErrNotFound {
	continue
	}
	return nil, err
	}
	matchedLabels = append(matchedLabels, &typesv1.LabelPair{
	Name: name,
	Value: value,
	})
	}

The high memory usage comes from us allocating a slice every iteration and even more egregiously, allocating a new typesv1.LabelPair on the heap every time we have a label name/value match.

This PR changes getUniqueLabelsSets to use a slice pool strategy, where we allocate a pool of the exact size and fill it with pointers to heap memory. We reuse this pool instead of allocating new memory each iteration of postings.Next(). If we need the contents of the pool, we explicitly copy out of the pool. This substantially reduces memory usage.

After the change, the new flamegraph shows getUniqueLabelsSets using ~56mb of memory:

And some benchmarks using the same 7.7mb index.tsdb:

Name	iterations	ns/op	B/op	allocs/op
old	37	27478623	9061538	188762
new	39	26336128	1681138	83927
change		-4.1%	-81.4%	-55.5%

Of course, now we have the problem of index.(*Reader).LabelValueFor using a lot of memory, but this is a significant and simple enough step that I think it's justifiable to merge on its own.

[cyriltovena]

LGTM !!!!!!