Incorporate DocValuesSkipper into IndexOrDocValuesQuery's cost decision

[mayya-sharipova]

IndexOrDocValuesQuery chooses between the index side and the doc-values side using a cost heuristic that predates doc-values skippers. The decision is driven by the index side's cost (with a fixed penalty applied to doc values); it has no awareness that the doc-values side may carry a DocValuesSkipper.

When a skipper is present and effective (values well-correlated with doc order, e.g. a primary/secondary index sort or naturally monotonic data), the doc-values side can skip whole blocks and be dramatically cheaper than the index side. But because the skipper never enters the cost model, IndexOrDocValuesQuery keeps choosing the index side — particularly for a standalone range, where it always does — and the skipper's benefit is left on the table.

The core gap is that the doc-values range scorer doesn't expose a meaningful, skipper-aware cost for the planner to use (see #15981, where SkipBlockRangeIterator.cost() currently returns NO_MORE_DOCS).

Related issues

• Improve clause ordering for multi-field DocValues range conjunctions #15981 — Improve clause ordering for multi-field DocValues range conjunctions (same missing primitive: a skipper-aware DV cost())
• TermsQuery as MultiTermQuery can dramatically overestimate its cost #12483 — TermsQuery as MultiTermQuery can dramatically overestimate its cost (the index-side half of the same heuristic)
• Instrument IndexOrDocValuesQuery to report on its decisions #13442 — Instrument IndexOrDocValuesQuery to report on its decisions
• Use SkipBlockRangeIterator as approximation in SortedNumericDocValuesRangeQuery #15954 — SortedNumericDocValuesRangeQuery now uses a skipper-backed iterator
• Optimize filtering on the primary index sort field #15139 — Optimize filtering on the primary index sort field