optimize sequence number calculation and reduce search requests in doc level monitor execution

[eirsep]

Optimize sequence number calculation and reduce search requests by n, where n is number of shards being queried in the execution

Issue #, if available:
#1409

Description of changes:
Use the first shard search request on each shard to compute max sequence number instead of making a search call simply to calculate the value.
Fetch data in descending order of sequence numbers to directly calculate the max seq_no

New heuristic:
take an example of one shard
in current iteration: previous seq_no = 10000, current max seq_no= 40000

first iteration of search shard(which also determines the max sequence number) : TO=int_max, FROM=prev_seq_no : calculate max_seq number
second iteration : TO=max_seq_no-10000 FROM=prev_seq_no
further iterations : TO=TO-10000 FROM=prev_seq_no till while to>from

in first iteration we get first 10k results and also calculate the max sequence number
in second iteration we reduce (TO) variable to maxSeqNo -10000
and query again and we continue this loop until we have seen all docs up untill the previous sequence number

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[lezzago]

Are we sure we do not need suspend anymore? I recall we needed it before

[eirsep]

we needed to do suspend earlier because we had a search call to calculate max seq_no being made within the method.
we have removed the search call as we calculate the max seq_no in the first pass. hence no need of a suspend

[lezzago]

Why do we need this while logic? Also it seems like we reduce the to by 10000 from the current fetched seqNo?

[eirsep]

take an example of one shard
in current iteration: previous seq_no = 10000, current max seq_no= 40000

first iteration of search shard(which also determines the max sequence number) : TO=int_max, FROM=prev_seq_no : calculate max_seq number
second iteration : TO=max_seq_no-10000 FROM=prev_seq_no
third iteration : TO=TO-10000 FROM=prev_seq_no

in first iteration we get first 10k results and also calculate the max sequence number
in second iteration we reduce (TO) variable to maxSeqNo -10000
and query again and we continue this loop until we have seen all docs up untill the previous sequence number

[eirsep]

made a change to set TO variable of next iteration as 1 less than least seq no from list of docs fetched in current search

[lezzago]

Are we only fetching 10,000 docs and is that why we chose 10,000? If so, this is not right. Sequence numbers are incremented for every new write operation on the index and that includes deletion.

[eirsep]

earlier logic was completely wrong
it calculated the max sequence number and assumed it will always be less than (prev_seq_no+10000) ans hence made only one search call with a hard coded size of from=prev_seq to = max_seq but size =10k

explained the current logic in the above comment: #1445 (comment)

[opensearch-trigger-bot]

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/alerting/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/alerting/backport-2.x
# Create a new branch
git switch --create backport-1445-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 faaf5520a71ce1b213968eadace6e7689320d997
# Push it to GitHub
git push --set-upstream origin backport-1445-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/alerting/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport-1445-to-2.x.