Refactor fuzziness interface on query builders

[noCharger]

Signed-off-by: noCharger lingzhichu.clz@gmail.com

Description

Refactor fuzziness interface on query builders

#3749 is more of a matter of method signature consistency than of a bug. Here's the trade-off between taking Fuzziness class everywhere VS take Object everywhere (discussed with @msfroh offline):

Take Fuzziness class everywhere (QueryStringQueryBuilder way) - Recommanded

• Pros:
  • Complie-time validation of an input value that must be of the Fuzziness typed object.
  • API is more self-documenting (since an API that takes Object could mean anything).
• Cons:
  • Requires code change by REST high-level client users who were passing a string or number (ex: "Auto", 0, 1, 2)
  • REST high-level client users must create Fuzziness object by calling Fuzziness.build() or invoke static variables like Fuzziness.ZERO, which is on a class marked @opensearch.internal

Take Object everywhere (MultiMatchQueryBuilder way)

• Pros:
  • Backward-compatible with existing behavior.(If someone is already passing a Fuzziness , it will still work based on Fuzziness.build() implementation)
  • Reduces need for users to use Fuzziness.build() directly, which is good since it’s marked @opensearch.internal.
• Cons:
  • API is less self-documenting.
  • Makes it easier to pass invalid values that only show up at runtime (The querybuilders also marked @opensearch.internal so not recommanded to call it directly from users)
  • From @reta: using Object is very discouraging it reads literally "any reference" (in Java).

Issues Resolved

#3749

Check List

• New functionality includes testing.
  • All tests pass
• 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: SUCCESS ✅
• URL: https://build.ci.opensearch.org/job/gradle-check/7527/
• CommitID: 6645745

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: SUCCESS ✅
• URL: https://build.ci.opensearch.org/job/gradle-check/7528/
• CommitID: 19c050f

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/7567/
• CommitID: 7145fce
  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/7577/
• CommitID: 4970f27
  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: SUCCESS ✅
• URL: https://build.ci.opensearch.org/job/gradle-check/7755/
• CommitID: e310470

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: SUCCESS ✅
• URL: https://build.ci.opensearch.org/job/gradle-check/7756/
• CommitID: beff85c

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/7792/
• CommitID: 50db83d
  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?

[dblock]

Let's talk about CHANGELOG?

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: SUCCESS ✅
• URL: https://build.ci.opensearch.org/job/gradle-check/7955/
• CommitID: b454712

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: SUCCESS ✅
• URL: https://build.ci.opensearch.org/job/gradle-check/7975/
• CommitID: 2ddb532

[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-5433-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 d3f6dfab89720df155ee9cb4789aa642c2238057
# Push it to GitHub
git push --set-upstream origin backport/backport-5433-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-5433-to-2.x.