Fixed bulk index requests in BWC tests and hardened assertions

[nibix]

Description

So far, the BWC test SecurityBackwardsCompatibilityIT.testDataIngestionAndSearchBackwardsCompatibility() did not ingest any documents, as the submitted bulk requests were invalid.

The test already asserted that _bulk API calls returned a 200 OK HTTP status. However, this is not sufficient, as the _bulk API also returns a 200 status if processing of the bulk items fails. Such failures are only reflected item-wise in the response body. This indeed happened, as the test erroneously serialized a string containing the JSON document again as JSON, creating a JSON string containing JSON. This was rejected by OpenSearch.

This is now fixed - additional assertions have been created to verify that the items of the bulk request are actually indexed.

Additionally, the DLS rules of the user would not match any of the ingested documents. This would have caused the _search API always to return empty result sets - even if any documents were ingested.

The indexed test documents were adjusted to have proper genre attributes which can match the configured DLS rule. Additional assertions were added that verify that the DLS and FLS rules are correctly applied to the result set.

• Category: Test fix
• Why these changes are required? - the test did not cover as much functionality as it should
• What is the old behavior before changes and new behavior after changes? - no changes

Testing

• Verified behavior in CI

Check List

• Commits are signed per the DCO using --signoff

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.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.70%. Comparing base (703d40f) to head (798ccdb).
Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4817      +/-   ##
==========================================
- Coverage   70.99%   70.70%   -0.29%     
==========================================
  Files         310      310              
  Lines       20938    20938              
  Branches     3326     3326              
==========================================
- Hits        14865    14805      -60     
- Misses       4325     4389      +64     
+ Partials     1748     1744       -4     

see 9 files with indirect coverage changes

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

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

[cwperks]

@nibix Can you create a manual backport for this PR? I suspect its due to the difference between Apache HttpCliient5 on main vs Apache HttpClient4 on 2.x

[nibix]

@nibix Can you create a manual backport for this PR? I suspect its due to the difference between Apache HttpCliient5 on main vs Apache HttpClient4 on 2.x

Sorry, I missed this request. Will do asap.