…elastic#51708)

This change ensures that the rewrite of the shard request is executed in the network thread or in the refresh listener when waiting for an active shard. This allows queries that rewrite to match_no_docs to bypass the search thread pool entirely even if the can_match phase was skipped (pre_filter_shard_size > number of shards). Coordinating nodes don't have the ability to create empty responses so this change also ensures that at least one shard creates a full empty response while the other can return null ones. This is needed since creating true empty responses on shards require to create concrete aggregators which would be too costly to build on a network thread. We should move this functionality to aggregation builders in a follow up but that would be a much bigger change.
This change is also important for elastic#49601 since we want to add the ability to use the result of other shards to rewrite the request of subsequent ones. For instance if the first M shards have their top N computed, the top worst document in the global queue can be pass to subsequent shards that can then rewrite to match_no_docs if they can guarantee that they don't have any document better than the provided one.

…#51708) (#51979)

This change ensures that the rewrite of the shard request is executed in the network thread or in the refresh listener when waiting for an active shard. This allows queries that rewrite to match_no_docs to bypass the search thread pool entirely even if the can_match phase was skipped (pre_filter_shard_size > number of shards). Coordinating nodes don't have the ability to create empty responses so this change also ensures that at least one shard creates a full empty response while the other can return null ones. This is needed since creating true empty responses on shards require to create concrete aggregators which would be too costly to build on a network thread. We should move this functionality to aggregation builders in a follow up but that would be a much bigger change.
This change is also important for #49601 since we want to add the ability to use the result of other shards to rewrite the request of subsequent ones. For instance if the first M shards have their top N computed, the top worst document in the global queue can be pass to subsequent shards that can then rewrite to match_no_docs if they can guarantee that they don't have any document better than the provided one.

Relates #51708

Relates #51708

Relates #51708

We need to either exclude null responses from the scroll search response 
or always create a search context for every target shards, although that
scroll query can be written to match_no_docs. Otherwise, we won't find
search_context for subsequent scroll requests.

This commit implements the latter option as it's less error-prone.

Relates #51708

We need to either exclude null responses from the scroll search response
or always create a search context for every target shards, although that
scroll query can be written to match_no_docs. Otherwise, we won't find
search_context for subsequent scroll requests.

This commit implements the latter option as it's less error-prone.

Relates #51708

We might leak a searcher if the target shard is removed (i.e., its index 
is deleted) or relocated while we are creating a SearchContext from a
SearchRewriteContext.

Relates #51708
Closes #52021

I labelled this non-issue for an unreleased bug introduced in #51708.

We might leak a searcher if the target shard is removed (i.e., its index
is deleted) or relocated while we are creating a SearchContext from a
SearchRewriteContext.

Relates #51708
Closes #52021

I labelled this non-issue for an unreleased bug introduced in #51708.

This commit, built on top of #51708, allows to modify shard search requests based on informations collected on other shards. It is intended to speed up sorted queries on time-based indices. For queries that are only interested in the top documents.

This change will rewrite the shard queries to match none if the bottom sort value computed in prior shards is better than all values in the shard.
For queries that mix top documents and aggregations this change will reset the size of the top documents to 0 instead of rewriting to match none.
This means that we don't need to keep a search context open for this shard since we know in advance that it doesn't contain any competitive hit.

This commit, built on top of #51708, allows to modify shard search requests based on informations collected on other shards. It is intended to speed up sorted queries on time-based indices. For queries that are only interested in the top documents.

This change will rewrite the shard queries to match none if the bottom sort value computed in prior shards is better than all values in the shard.
For queries that mix top documents and aggregations this change will reset the size of the top documents to 0 instead of rewriting to match none.
This means that we don't need to keep a search context open for this shard since we know in advance that it doesn't contain any competitive hit.

Field level security was interacting in bad ways with the can-match phase on frozen tier shards (interaction between
FieldSubsetReader and RewriteCachingDirectoryReader). This made can-match phase fail, which in the normal case
would result in extra load on the frozen tier, and in the extreme case (in interaction with #51708) made searches fail.

This is a bug that was indirectly introduced by #78988.

Closes #82044

Field level security was interacting in bad ways with the can-match phase on frozen tier shards (interaction between
FieldSubsetReader and RewriteCachingDirectoryReader). This made can-match phase fail, which in the normal case
would result in extra load on the frozen tier, and in the extreme case (in interaction with elastic#51708) made searches fail.

This is a bug that was indirectly introduced by elastic#78988.

Closes elastic#82044

Field level security was interacting in bad ways with the can-match phase on frozen tier shards (interaction between
FieldSubsetReader and RewriteCachingDirectoryReader). This made can-match phase fail, which in the normal case
would result in extra load on the frozen tier, and in the extreme case (in interaction with elastic#51708) made searches fail.

This is a bug that was indirectly introduced by elastic#78988.

Closes elastic#82044

Field level security was interacting in bad ways with the can-match phase on frozen tier shards (interaction between
FieldSubsetReader and RewriteCachingDirectoryReader). This made can-match phase fail, which in the normal case
would result in extra load on the frozen tier, and in the extreme case (in interaction with #51708) made searches fail.

This is a bug that was indirectly introduced by #78988.

Closes #82044

Field level security was interacting in bad ways with the can-match phase on frozen tier shards (interaction between
FieldSubsetReader and RewriteCachingDirectoryReader). This made can-match phase fail, which in the normal case
would result in extra load on the frozen tier, and in the extreme case (in interaction with #51708) made searches fail.

This is a bug that was indirectly introduced by #78988.

Closes #82044

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>