This change automatically pre-sort search shards on search requests that use a primary sort based on the value
of a field. When possible, the can_match phase will extract the min/max (depending on the provided sort order) values
of each shard and use it to pre-sort the shards prior to running the subsequent phases. This feature can be useful to
ensure that shards that contain recent data are executed first so that intermediate merge have more chance to contain
contiguous data (think of date_histogram for instance) but it could also be used in a follow up to early terminate sorted
top-hits queries that don't require the total hit count. The latter could significantly speed up the retrieval of the most/least
recent documents from time-based indices.
I took two shortcuts here:
* I reused the can_match phase to add the required information for the shard sort. We could instead introduce a new phase
 but it make sense to me to use the existing phase to add more informations as long as the additional ops are lightweight.
* The shard sort is done automatically if the primary search sort is based on a field. However this sorting only makes sense
if the range of values in each shard doesn't overlap (time-based indices sorted on timestamp for instance). We could add
a new option to enable/disable this behavior or even add an additional `shard_sort` criteria but I also like the fact that
users don't need to set any option to benefit from this feature.

Relates elastic#49091

…reFilterSearchPhase.java

Co-Authored-By: Adrien Grand <jpountz@gmail.com>

…reFilterSearchPhase.java

Co-Authored-By: Adrien Grand <jpountz@gmail.com>

…reFilterSearchPhase.java

Co-Authored-By: Adrien Grand <jpountz@gmail.com>

…reFilterSearchPhase.java

Co-Authored-By: Adrien Grand <jpountz@gmail.com>

…ardsIterator.java

Co-Authored-By: Adrien Grand <jpountz@gmail.com>

Co-Authored-By: Adrien Grand <jpountz@gmail.com>