Use query source to detect non-null docs

[dnhatn]

One of the slowest parts of time-series queries is reading metric values - it accounts for 30% of the profiler time for the following query:

TS my*
| WHERE `metrics.system.memory.utilization` IS NOT NULL
        AND @timestamp >= "2025-07-25T14:55:59.000Z"
        AND @timestamp <= "2025-07-25T16:25:59.000Z"
| STATS AVG(AVG_OVER_TIME(`metrics.system.memory.utilization`)) BY host.name, BUCKET(@timestamp, 1h)

This is because the metrics.system.memory.utilization field is sparse, requiring iteration over its DISI to find value indices when reading values. This change adds a flag named nullsFiltered to the column reader, signaling that all target docs have values for the field. This enables optimizations such as skipping value index lookups with DISI and performing bulk copying.

We can safely do this because if the filter WHERE metrics.system.memory.utilization IS NOT NULL is pushed down to Lucene, then every document returned from the Lucene operator will have a value for the metrics.system.memory.utilization field.

I was able to make changes that reduce the execution time for reading sparse metric values to be comparable with reading dense fields (like timestamp). To keep this PR small, I will open the codec-related changes in a separate PR.

[dnhatn]

To the reviewers: except for the comments, most of the changes add a new parameter to the column reader.

[dnhatn]

Here, we extract fields from the query that can be considered nullsFiltered when reading values. The nullsFiltered flag passed to each FieldInfo.

[kkrik-es]

Is this done only for TS or for FROM too? For the latter, I wonder if ignoring nulls is desired.

[dnhatn]

It should work for both, but it will be a no-op. Optimizations can be enabled at the codec level, and only possible with the TSDB codec now.

[dnhatn]

This can be expensive, so it is only enabled with assertions.

[dnhatn]

We pass the nullsFiltered from FieldInfo to column reader.

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[elasticsearchmachine]

Pinging @elastic/es-storage-engine (Team:StorageEngine)

[dnhatn]

[kkrik-es]

Should we also find and ignore coalence? Or is this part of default?

[kkrik-es]

Looks good!

One note: what happens if we have multiple field metrics? For instance:

TS metrics 
| WHERE cpu_usage IS NOT NULL OR memory_usage IS NOT NULL
| STATS max(avg_over_time(cpu_usage)), max(avg_over_time(memory_usage)) BY tbucket(1 hour)

I'd think we don't necessarily get dense values here? If so, is this covered?

[dnhatn]

TS metrics 
| WHERE cpu_usage IS NOT NULL OR memory_usage IS NOT NULL
| STATS max(avg_over_time(cpu_usage)), max(avg_over_time(memory_usage)) BY tbucket(1 hour)

We won't be able to infer nullsFiltered from that query for either cpu_usage or memory_usage. Yes, we have tests for this case.

[dnhatn]

Thanks Kostas!