Adding depth check in doc parser for deep nested document

[nkumar04]

Description

Added a depth level check within the document parser context. The depth level is incremented for each nested object parsing and decremented when parsing is done. If the depth level crosses a threshold, document parser throws a parsing exception and an error is returned in the response, stating the reason of the failure

Issues Resolved

Closes issue (#5195)

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/6753/
• CommitID: fe1f692
  Please examine the workflow log, locate, and copy-paste the failure 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/7424/
• CommitID: c2b1c23
  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/7425/
• CommitID: da33086
  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/7429/
• CommitID: 174883a

[dblock]

Add to CHANGELOG. We'll also need to document this.

How does this alter the default behavior? If I understand correctly now the mapping depth limit is now enforced - what is its default value?

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: UNSTABLE ❕
• TEST FAILURES:

      1 org.opensearch.cluster.allocation.AwarenessAllocationIT.testThreeZoneOneReplicaWithForceZoneValueAndLoadAwareness

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

[github-actions]

Gradle Check (Jenkins) Run Completed with:

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

[codecov-commenter]

Codecov Report

Merging #5199 (2c6c8b9) into main (28e9b11) will increase coverage by 0.02%.
The diff coverage is 87.93%.

@@             Coverage Diff              @@
##               main    #5199      +/-   ##
============================================
+ Coverage     70.98%   71.01%   +0.02%     
+ Complexity    58669    58655      -14     
============================================
  Files          4763     4764       +1     
  Lines        279945   280010      +65     
  Branches      40418    40425       +7     
============================================
+ Hits         198731   198843     +112     
+ Misses        64988    64858     -130     
- Partials      16226    16309      +83     

Impacted Files	Coverage Δ
...a/org/opensearch/test/OpenSearchIntegTestCase.java	56.35% <0.00%> (-0.32%)	⬇️
...pensearch/common/settings/FeatureFlagSettings.java	50.00% <50.00%> (ø)
.../java/org/opensearch/common/util/FeatureFlags.java	80.00% <88.88%> (+30.00%)	⬆️
...va/org/opensearch/index/mapper/DocumentParser.java	86.45% <89.65%> (+0.21%)	⬆️
...org/opensearch/common/settings/SettingsModule.java	85.81% <100.00%> (+0.29%)	⬆️
...java/org/opensearch/index/mapper/ParseContext.java	85.99% <100.00%> (+2.94%)	⬆️
server/src/main/java/org/opensearch/node/Node.java	87.17% <100.00%> (+0.01%)	⬆️
...regations/metrics/AbstractHyperLogLogPlusPlus.java	51.72% <0.00%> (-44.83%)	⬇️
...opensearch/persistent/PersistentTasksExecutor.java	22.22% <0.00%> (-44.45%)	⬇️
...pensearch/action/ingest/DeletePipelineRequest.java	31.25% <0.00%> (-37.50%)	⬇️
... and 502 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[dblock]

Will leave this to @reta since he had some concerns.

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: SUCCESS ✅
• URL: https://build.ci.opensearch.org/job/gradle-check/8789/
• CommitID: 997e763

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: UNSTABLE ❕
• TEST FAILURES:

      1 org.opensearch.index.termvectors.TermVectorsServiceTests.testWithIndexedPhrases

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

[reta]

@nkumar04 could you rebase please?

[nkumar04]

Will leave this to @reta since he had some concerns.

Hi @dblock , @reta has approved the PR. Please let me know if you have any comment or suggestion. Thanks

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/10810/
• CommitID: d45b0eb
  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.extensions.ExtensionsManagerTests.classMethod
      1 org.opensearch.extensions.ExtensionsManagerTests.testInitialize

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

[nkumar04]

@nkumar04 could you rebase please?

done.

[dblock]

Looks like this needs another rebase, sorry. I am traveling, will be slow to reply. Hope other maintainers can help merge.

[github-actions]

Gradle Check (Jenkins) Run Completed with:

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

[andrross]

I'm assuming this is safe to backport, as it is a fix to a stack overflow label. I'm adding the backport label now but we'll also have to fix up the changelog entry and move it to the Unreleased 2.x section.

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