Slow query performance when using sort_by_field on queries with few matches

[Windforce17]

Describe the bug
I noticed that the following query becomes significantly slower when sort_by_field is specified:

When I remove sort_by_field, the same query becomes very fast. I also observed a large increase in fast_field_cache evict_bytes while running the query.

However, the query only returns fewer than 10 documents, which is far below max_hits. Based on this behavior, it seems that the sort operation may be scanning or loading fast field data before applying the query filter. If that is the case, it appears inefficient and unexpected.

{"query":"trace_id:\"0002e641f5b84161f35b907c8fce3039\"","max_hits":100,"start_timestamp":1771303321,"end_timestamp":1779079322,"sort_by_field":"span_start_timestamp_nanos"}

Steps to reproduce (if applicable)

1. Ingest a large number of traces so that the fast-field cache capacity is exceeded.
2. Run a trace query with sort_by_field enabled.
3. Compare the latency and fast_field_cache evict_bytes with the same query executed without sort_by_field.

Expected behavior
The query filter should be applied first, and sorting should only be performed on the matched documents. In this case, since the query matches fewer documents, adding sort_by_field should not significantly increase query latency or cause substantial fast-field cache eviction.

Configuration:

1. v0.9.0-rc
2. Index template: official otel-traces-v0_9 index

[trinity-1686a]

what happens is that for each split, we first download the part of the split needed to run the query (including the column used for sorting and aggregations), this phase is known as "warmup" in the code; and in a second phase we give those buffers and the query to tantivy, which does the work with the in-memory data.

Not downloading columns used in aggregations seems impossible without major changes, skipping the download of the sorting column might be feasible, but would be rather complex.
One idea which gives much of the result with hopefully a fraction of the complexity is described in #4202 : start by downloading everything needed for the split, but if from just downloading things we can already tell no document in it will match, we can abort in-progress downloads and don't run the tantivy phase. This would help with a query such as trace_id:0002e641f5b84161f35b907c8fce3039 where trace_id in itself is very selective, but not for field1:value1 AND field2:value2 where both appear in most split, but few if any document actually has both these fields set to these values