MQE: eliminate loops in BucketedPool

[charleskorn]

What this PR does

This PR eliminates the use of loops in BucketedPool. This gives a very mild speedup (<1%) to queries with many steps and many series.

It also removes the panics in both ring buffer's Append and Use methods. It's possible that the conditions that previously would have caused a panic could happen in the real world if a subquery selected enough points that it exceeded the maximum size of a slice returned from the FPoint or HPoint pool, so it seems safer to return an error here rather than crashing the process.

Which issue(s) this PR fixes or relates to

(none)

Checklist

• Tests updated.
• [n/a] Documentation added.
• [n/a] CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX].
• [n/a] about-versioning.md updated with experimental features.

[jhesketh]

I'd be curious to see a benchmark for this if possible please :-).

Also, regarding the power of 2 checks in the buffer, we could grow the capacity of the returned slice to the next power of 2. It doesn't help the pool or anything, but we can still potentially process it. We'd need some kind of additional limit for reasonableness though so it might not be worth it so long as the pool sizes are reasonable themselves.

[charleskorn]

We'd need some kind of additional limit for reasonableness though so it might not be worth it so long as the pool sizes are reasonable themselves.

I think the pool sizes are already reasonable themselves - and if we start running into this in the real world then we can easily adjust the pool limit.

[charleskorn]

I'd be curious to see a benchmark for this if possible please :-).

Most of our benchmarks see very mild impact (<1%), but for queries with many steps and many series, the impact is noticeable:

                                                                     │  before.txt  │             after.txt              │
                                                                     │    sec/op    │    sec/op     vs base              │
Query/a_2000,_range_query_with_100_steps/engine=Mimir-10                20.07m ± 3%   19.31m ±  1%  -3.79% (p=0.002 n=6)
Query/a_2000,_range_query_with_1000_steps/engine=Mimir-10               95.23m ± 5%   93.46m ±  4%  -1.87% (p=0.041 n=6)
Query/nh_2000,_range_query_with_100_steps/engine=Mimir-10               154.7m ± 1%   152.1m ±  1%  -1.74% (p=0.002 n=6)
Query/nh_2000,_range_query_with_1000_steps/engine=Mimir-10              832.5m ± 2%   810.3m ±  7%       ~ (p=0.065 n=6)

[jhesketh]

Neat, thanks!

[jhesketh]

This introduced a bug fixed in #10261