Add early termination support for concurrent segment search

[jed326]

Description

This PR adds support for partial results in the cases of timeouts for concurrent segment search.
"Full" partial results are not supported for early terminations because shard failures are expected in that case and thus the behavior between concurrent and non-concurrent search is already consistent. See #817 for more details.

We achieve this by swallowing the timeout exception in the ContextIndexSearcher.searchLeaf method and forces us to finish processing all of the leaves in both the sequential and concurrent cases.

Related Issues

Resolves #2586

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Commits are signed per the DCO using --signoff
• Commit changes are listed out in CHANGELOG.md file (See: Changelog)

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.

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/18522/
• CommitID: 917dc38
  Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
  Is the failure a flaky test unrelated to your change?

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/18523/
• CommitID: 90a37b8
  Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
  Is the failure a flaky test unrelated to your change?

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/18524/
• CommitID: 0173f13
  Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
  Is the failure a flaky test unrelated to your change?

[jed326]

The Gradle Check failure is for an unrelated test, but I am seeing a performance issue in the timeout case. I don't expect the timeout test to take 4x as long as the no timeout case. I see the same runtime over several runs.

[jed326]

Upon closer inspection this difference in time is actually due to ingesting 1000 docs for the timeout case vs only 10 for the no timeout case. When using 100 docs for both the time is much more aligned:

I'm going to keep the 1000 docs for the timeout case though so that we can keep the check that we are only getting a portion of the expected docs. With 100 docs and 1ms timeout I am seeing that the test still sometimes does collect all 100 docs before the timeout.

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/19440/
• CommitID: 819f20f
  Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
  Is the failure a flaky test unrelated to your change?

[jed326]

Test failures look unrelated but I'll rebase the branch and rerun the tests

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/19444/
• CommitID: bcda9fb
  Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
  Is the failure a flaky test unrelated to your change?

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: UNSTABLE ❕
• TEST FAILURES:

      2 org.opensearch.remotestore.SegmentReplicationRemoteStoreIT.classMethod
      1 org.opensearch.remotestore.SegmentReplicationRemoteStoreIT.testPressureServiceStats

• URL: https://build.ci.opensearch.org/job/gradle-check/19449/
• CommitID: 5fa3ba7
  Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

[jed326]

Looks like all the tests pass after rebasing, @reta I think we're good to merge then if no other comments. Thanks!

[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:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/backport-2.x
# Create a new branch
git switch --create backport/backport-8306-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 31e67c17ecc6eb70d28e991b13085411e961b5bd
# Push it to GitHub
git push --set-upstream origin backport/backport-8306-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/backport-2.x

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

[reta]

@jed326 sadly 2.x needs manual backport, could you please take care of it? thank you