MQE: improve performance of subqueries when the parent query is a range query with many steps

[charleskorn]

What this PR does

This PR is a follow-up PR to #9664.

This PR improves the performance of subqueries when the parent query is a range query with many steps.

It does this by changing the behaviour of the ring buffer implementations to search forwards through the buffer to find the end of the range when a subquery is being evaluated, rather than backwards. Searching backwards makes sense for range vector selectors, where there is expected to only be one point, if any, at the end of the buffer outside the range, but for subqueries in range queries it is expected that there will be many points at the end of the buffer outside the range, so it is usually faster to search from the beginning of the buffer.

I'd suggest reviewing each commit separately, as each builds on the previous one and incrementally improves things.

In benchmarking, peak memory consumption is unchanged, and latency is reduced for both subqueries and range vector selectors. For example:

goos: darwin
goarch: arm64
pkg: github.com/grafana/mimir/pkg/streamingpromql/benchmarks
cpu: Apple M1 Pro
                                                                                       │ original.txt │              final.txt              │
                                                                                       │    sec/op    │    sec/op     vs base               │
Query/rate(a_1[1m]),_range_query_with_1000_steps/engine=Mimir-10                         230.2µ ±  1%   218.0µ ±  2%   -5.30% (p=0.002 n=6)
Query/rate(a_100[1m]),_range_query_with_1000_steps/engine=Mimir-10                       7.707m ±  1%   7.086m ±  2%   -8.07% (p=0.002 n=6)
Query/rate(a_2000[1m]),_range_query_with_1000_steps/engine=Mimir-10                      134.3m ±  1%   124.3m ±  1%   -7.43% (p=0.002 n=6)
Query/rate(a_2000[1m]),_range_query_with_10000_steps/engine=Mimir-10                      1.356 ±  6%    1.253 ±  5%   -7.56% (p=0.002 n=6)
Query/rate(nh_1[1m]),_range_query_with_1000_steps/engine=Mimir-10                        705.2µ ±  1%   649.9µ ±  1%   -7.85% (p=0.002 n=6)
Query/rate(nh_100[1m]),_range_query_with_1000_steps/engine=Mimir-10                      44.71m ±  1%   43.46m ±  1%   -2.79% (p=0.002 n=6)
Query/rate(nh_2000[1m]),_range_query_with_1000_steps/engine=Mimir-10                     853.5m ±  1%   843.9m ±  4%        ~ (p=0.310 n=6)
Query/rate(nh_2000[1m]),_range_query_with_10000_steps/engine=Mimir-10                     8.723 ±  3%    8.573 ±  1%   -1.73% (p=0.002 n=6)
Query/sum_over_time(a_2000[10m:3m]),_range_query_with_1000_steps/engine=Mimir-10         172.4m ±  2%   129.6m ±  3%  -24.80% (p=0.002 n=6)
Query/sum_over_time(nh_2000[10m:3m]),_range_query_with_1000_steps/engine=Mimir-10         1.155 ±  2%    1.101 ±  1%   -4.68% (p=0.002 n=6)
Query/sum(sum_over_time(a_100[10m:3m])),_range_query_with_1000_steps/engine=Mimir-10     9.652m ±  1%   7.456m ±  1%  -22.75% (p=0.002 n=6)
Query/sum(sum_over_time(a_2000[10m:3m])),_range_query_with_1000_steps/engine=Mimir-10    177.2m ±  1%   133.6m ±  1%  -24.56% (p=0.002 n=6)

Which issue(s) this PR fixes or relates to

#9664

Checklist

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

[jhesketh]

lgtm, some nice collection of optimisations.

I think we can optimise the bucketed pools somewhat by enforcing the factor to be 2. I can look at doing that as a followup if you prefer though.

[jhesketh]

(nit, probably for follow up). I feel like First() and Last() should have the same signature. It seems weird to panic in one situation and return false for another.

[charleskorn]

Agreed, but I'd like to keep this for a separate PR as you suggest.

[jhesketh]

Just a nit on the test, not blocking on it :-).

lgtm 🚀