Avoid reading blocks in sort step of ReadGroup

This code implements ReadGroup on the storage side:
https://github.com/influxdata/influxdb/blob/master/storage/reads/group_resultset.go#L233
That’s the code that sorts all the series so we can group them. At first I thought maybe it’s just sorting the series keys, but I noticed that It calls a method seriesHasPoints
https://github.com/influxdata/influxdb/blob/master/storage/reads/group_resultset.go#L121
The purpose of this code is to avoid sorting the (potentially large number of) series keys that don't have any points in the request's time range. That looks to be actually doing I/O and reading the first block of data into memory for each series for which the predicate evaluates to true. This is a significant performance hit.

The problem here is that we are loading the first block of each series into memory before we even start reading the data, including those series that have no points in the request's time range.

Instead of doing this, we could just sort those series keys for series that have no points for the given range, and omit them from the result later. A potential problem with this approach is that we'll be constructing a larger number of sort keys, which would increase memory/gc pressure.

We should benchmark this work to ensure that it performs better. It would be good to hit the case where there are a large number of series, but tag values change rapidly across time, such that there are a large number of empty series for a sufficiently narrow range.

An alternative and more optimal way of addressing this problem would be to determine if a given series has no points in the request's time range without doing I/O.

We already filter out series based on predicates against tag keys (i.e., predicates from Flux filters that have been pushed down), so it seems feasible that we could evaluate the range here too. But I don't yet understand this code well enough to know if that's feasible.

Start with storage/reads/group_resultset.go, especially ReadGroup around line 233 and seriesHasPoints around line 121. Trace how series are sorted and how the first block is loaded, then compare the proposed sorting/filtering approaches. Add a benchmark covering many rapidly changing series and a narrow time range, and use it to verify reduced I/O and acceptable memory use.