The results of $search come out sorted by 'searchScore' (in cases where the sort argument is not specified as otherwise). If a $sort stage comes directly after $search, and the sort criteria is by the searchScore, the sort should be able to be removed, as it should pass the documents in and out it in the same order.

The $sort that follows the $search can come from being explicitly specified, or from desugaring of another stage that requires sorting like $setWindowFields. The optimizing code should not need to differentiate these cases, but both types should be tested for correctness.

Note: This optimization should only apply to single node environments, as $search pipelines that have subsequent $sort stages are broken apart as a $search on the shard nodes, with a $mergeCursors stage followed by the $sort on the merging (mongos) node. This part of the optimization will be handled separately, and is more generic as many pipelines (other than $search ones) in a sharded environment may have a $mergeCursors stage followed by a $sort.

Note: This optimization should only apply to pipelines where the $sort comes directly after the $search stage. This optimization should be generalizable to cases where stages that do not affect the sort order of the documents come in-between the $search and $sort, however there are some pre-requisites to tackle before we can implement this generalization, which will be handled in subsequent tickets.