SOLR-17841: Use DocSetCollector for multithreaded DocSet(Faceted) search

[punAhuja]

https://issues.apache.org/jira/browse/SOLR-17841

Description

Multithreaded(MT) search was slower than Singlethreaded(ST) search in the case of faceted queries. Faceted queries need a DocSet. ST already builds that with DocSetCollector. MT used a custom FixedBitSetCollector instead, and that made faceted search slower with MT on.

This PR fixes that DocSet path so enabling MT no longer makes faceting worse.

Solution

Two changes in MultiThreadedSearcher / SolrIndexSearcher:

1. Multithreaded DocSet search now uses DocSetCollector, same as the single-threaded path. Each thread collects its own DocSet, then we OR them together. The old FixedBitSetCollector was only used here, so I removed it.
2. multiThreaded=true now also needs a searcher thread pool. If indexSearcherExecutorThreads=0, we used to take the multithreaded path anyway and it could get very slow. That case now falls back to single-threaded.
   I used an AI coding assistant (Cursor) while investigating and drafting the change. I reviewed the diff, ran the tests, and did the benchmarks myself.

Tests

Unit test: TestMultiThreadedSearcher.testMultiThreadedDocSetMatchesSingleThreaded — same query, needDocSet=true, ST vs MT DocSets must match on a multi-segment index.

Latency was measured with solr-bench (one client query at a time; searcher
pool -Dsolr.searchThreads=-1). Suites, generator, NoMerge configset, and
how to run it:

https://github.com/SearchScale/solr-bench/tree/puneet/SOLR-17841-mt-search

I compared the same 1M-doc index merged vs forced to ~500 segments
(NoMergePolicy, flush every 2000 docs). Queries are event_time range +
event_type filter, with and without facets.

	mean	p50	p95
facet, few segments, MT before	~15.1	~6.0	~66
facet, few segments, after (ST / MT)	7.14 / 7.65	6.38 / 6.86	12.43 / 13.80
plain, many segments (ST / MT)	4.55 / 3.36	2.75 / 2.78	21.56 / 7.75
facet, many segments (ST / MT)	15.79 / 14.78	12.22 / 12.44	38.28 / 30.59

After the fix, facet MT is no longer worse on a normal index. With many
segments MT can win, especially on plain queries and p95.

NOTE: Still investigating whether MT can actually beat ST more broadly.

This PR only addresses the DocSet collector used for faceting. After the change, facet MT is no longer worse on a normal index, and with many segments MT can win (especially plain queries and p95).
Renato's findings on SOLR-17841 look like a separate bottleneck. Even with 50M docs force-merged to 5 segments, range queries were ~5× slower under MT; the profile pointed at SolrRangeQuery / FixedBitSet.or, not this collector. I want to look at that next.

Checklist

Please review the following and check all that apply:

• I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
• I have created a Jira issue and added the issue ID to my pull request title.
• I have given Solr maintainers access to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation)
• I have developed this patch against the main branch.
• I have run ./gradlew check.
• I have added tests for my changes.
• I have added documentation for the Reference Guide
• I have added a changelog entry for my change

[dsmiley]

Thanks for this!
What is "many" segments vs "few" ?

Did you consider & reject use of the solr/benchmark (JMH) benchmark system?

[punAhuja]

Thanks for this! What is "many" segments vs "few" ?

Did you consider & reject use of the solr/benchmark (JMH) benchmark system?

Multithreaded search parralelizes searching on different segments. So more segments = more parallelization. I was testing on a dataset with 1M docs, so I configured it to use NoMerge policy and flush at every 2k docs so I have more segments in the index.
So,
few segments -> TieredMergePolicy, no maxBufferedDocs override
many segments(500 segments) -> NoMergePolicy and maxBufferedDocs=2000

I didn't consider solr/benchmark as I have used solr-bench and am comfortable with it.

[dsmiley]

I find this method rather inelegant. It takes several args, one of which is a boolean (problematic to discern meaning at call-site in Java; no named-args). The method's only purpose is to decide yes/no on something. Notice that this method takes a postFilter and we do a null check. I think it'd be slightly improved to replace this boolean you added with the executor itself.

[dsmiley]

I find this method rather inelegant. It takes several args, one of which is a boolean (problematic to discern meaning at call-site in Java; no named-args). The method's only purpose is to decide yes/no on something. Notice that this method takes a postFilter and we do a null check. I think it'd be slightly improved to replace this boolean you added with the executor itself.