GetMetrics use second pass

[mdisibio]

What this PR does:
There is a subtle behavior issue in the metrics summary api (traceqlmetrics/GetMetrics) that needs to be fixed, but doing so isn't tenable without also addressing the memory inefficiencies in the second pass layer in the parquet encodings.

** Main goal **
The metrics summary api is currently putting the groupBy conditions in the first pass, so this isn't quite working as expected. If you group by span.foo (which doesn't exist), it should return a series with nil values (all the spans matching the query that don't have this attribute), but instead it returns nothing. You can think of it as the difference between these two queries:

{ span.foo }

vs:

{ } | select(span.foo)

We need it to operate like the latter. So this updates traceqlmetrics.GetMetrics to move the groupBy to the second pass (the same as select()).

** Memory impact **
Doing that starting hitting a lot of memory inefficiencies in the second pass layer. This isn't normally an issue because searches typically hit a smallish number of spansets (1000 or less) but the metrics summary api will hit millions. There is ~10x increase in memory in BenchmarkBackendBlockGetMetrics without these changes.

There are two main changes:

1. Export the pooling methods in parquetquery to allow external iterators to get and put things back to the pool. The rebatchIterator and bridgeIterator need to do this. They were creating a lot of IteratorResults outside the pool.
2. Add a Release method to traceql.Spanset so the final user of the data (traceqlmetrics.GetMetrics) can return the spansets back to the pools. I tried a couple of variations of this and I'm happy with how this ended up. It's optional and things fallback to GC if this is never used (and in fact I didn't update any other traceql areas to use it.)

Which issue(s) this PR fixes:
Fixes n/a

Checklist

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

[joe-elliott]

ci is mad at you, but lgtm.

this should improve memory usage on traceql as well?

[mdisibio]

this should improve memory usage on traceql as well?

Right, since it is all the same pipeline any query using select() will also benefit. But to a lesser degree as mentioned because searches typically don't inspect as many spansets as metrics calls.