Flat object field use IndexOrDocValuesQuery to optimize query

[kkewwei]

Description

The pr mainly support the two features:
1.flat object field use IndexOrDocValuesQuery to optimize query.
2.flat object field delegate to keyword field to reduce code duplication.

Related Issues

Resolves #11635 #11537

Check List

• Functionality includes testing.
• API changes companion pull request created, if applicable.
• Public documentation issue/PR created, if applicable.

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 result for 9da1d18: FAILURE

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?

[kkewwei]

After #13853 is merged, the pr can be merged later.

[github-actions]

❌ Gradle check result for 48b7f47: FAILURE

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?

[harshavamsi]

@kkewwei looks like a bunch of flat_object tests are failing. I can review once we have green gradle!

[kkewwei]

❌ Gradle check result for 6b21e8b: FAILURE

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?

SpecificClusterManagerNodesIT.testElectOnlyBetweenClusterManagerNodes #16015

[github-actions]

✅ Gradle check result for bd77d36: SUCCESS

[github-actions]

✅ Gradle check result for 1be6b1e: SUCCESS

[msfroh]

Overall, this is looking pretty good to me. Thanks @kkewwei!

I posted one question about the behavior of fuzzy query (though I guess it could apply to some of the other queries? Or maybe not. I think prefix, regexp, wildcard, and range queries all force the dot-path to match exactly.) I don't think it's a blocker, but I'm mostly curious to know if we can get possibly surprising behavior.

[github-actions]

❌ Gradle check result for 74086ae: FAILURE

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 result for b9366dc: FAILURE

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 result for cdcb03a: SUCCESS

[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/OpenSearch/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch/backport-2.x
# Create a new branch
git switch --create backport/backport-14383-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 9ddee61b1b4eafebe9b4d30e997b40178c939a5e
# Push it to GitHub
git push --set-upstream origin backport/backport-14383-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch/backport-2.x

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

[msfroh]

Darn... auto-backport failed. Probably just a conflict on the changelog.

@kkewwei, could you please open a manual backport PR?