DEVPROD-11215 Create benchmarks for TS bucket-level optimizations

[mattBoros]

Extends TimeseriesTsbsOptimizations.yml with benchmarks that will be affected by no longer doing the bucket-level rewrites in SERVER-93874.
Created TimeseriesExtendedRange.yml since there's future work for extended range optimizations, and also since SERVER-93874 will remove a block-processing optimization on $max. We can keep all benchmarks specific to extended range in TimeseriesExtendedRange.yml.

[mattBoros]

The other query we talked about {$group: {_id: time, a: {$min/max: meta}}} wasn't affected, since it can't use bucket-level rewrites anyway.

[mattBoros]

I wrote the two benchmark files, all other files are automatically generated by genny

Some results:
When bucket-level rewrites are removed and the queries go through BP now, we see a ~3.1x increase in latency. (TimeseriesTsbsOptimizations.yml changes)
When we prevent BP from using the control.max field when its <1970, we see a ~4.4x increase in latency. (TimeseriesExtendedRange.yml changes)

[galon1]

I just had one main question but most of the changes look good

[galon1]

Do you think QE should own these? I feel like QI will probably re-enable the optimization, but I'm not sure

[mattBoros]

Oh yea, QI will probably be more involved in this benchmark in the future. I'll change it

[galon1]

Both extended range and not extended range won't be applicable for $group rewrites with $min on the timeField because it's a rounded down value right? So we shouldn't be losing performance here between extended range and not. I'm not saying this isn't relevant here but it should be around the same for extended range and normal time-series collections

[mattBoros]

Yea! That's true. I was thinking it's probably best to cover both $min/$max instead of just $max, while were writing these benchmarks. Like if in the future we run into a similar $min bug, we'll already have this benchmark and it's perf history.