Avoid exhaustively sorting buckets that will be discarded due to the "offset" search parameter

[loiclec]

Meilisearch works by performing a bucket sort of the documents that match a search query (as explained shortly in the Meilisearch documentation).

For example, with the following ranking rules:

words
typo
proximity

Then, conceptually, the following things happen:

1. words prepares the first bucket of documents. These are the documents which contain all the words from the search query. It gives this bucket to the next ranking rule, typo.
2. typo prepares a sub-bucket by finding all the documents which contain these words from the search query with 0 typo. It gives this sub-bucket to proximity.
3. proximity prepares a sub-sub-bucket by finding all documents where consecutive words in the query are also consecutive in the document.
4. Since there are no more ranking rules afterward, this sub-sub-bucket is returned. If we don't have enough results yet, we ask proximity for its next sub-bucket. If there aren't any, we ask typo, and finally words again. We go up and down the ranking rules in this way until we have exhaustively sorted enough documents.

However, if a user asks for results starting from offset 500, for example, we should apply a slightly different logic. When a ranking rule computes its bucket, it should check whether any document in this bucket could possibly be returned in the results. If not, it should discard this bucket and compute the next one.

Currently, this logic that skips sorting a bucket if it doesn't intersect with the possible range of results is not implemented. In practice, it means that searches given a large offset parameter will be much slower than necessary.

[loiclec]

Fixed by #3542