[Backport 2.x] React to changes in ActionListener in core

[RyanL1997]

Description

Manual backport for #3153 of React to changes in ActionListener in core
Also includes a fix for a call to XContentHelper.toXContent in response to opensearch-project/OpenSearch#9156

Issues Resolved

• Relate [Backport 2.x] [Refactor] Task foundation classes to core library - pt 1 (#9082) OpenSearch#9352
• Relate [Build Break] React to changes in ActionListener and ActionResponse from #9082 #3153

Check List

• New functionality includes testing
• New functionality has been documented
• 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

Merging #3182 (02ba199) into 2.x (4a14af4) will decrease coverage by 0.04%.
Report is 1 commits behind head on 2.x.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##                2.x    #3182      +/-   ##
============================================
- Coverage     62.22%   62.19%   -0.04%     
+ Complexity     3312     3310       -2     
============================================
  Files           265      265              
  Lines         19502    19502              
  Branches       3328     3328              
============================================
- Hits          12136    12130       -6     
- Misses         5741     5744       +3     
- Partials       1625     1628       +3     

Files Changed	Coverage Δ
.../opensearch/security/OpenSearchSecurityPlugin.java	84.26% <ø> (ø)
.../security/action/whoami/TransportWhoAmIAction.java	28.57% <ø> (ø)
...nsearch/security/action/whoami/WhoAmIResponse.java	0.00% <ø> (ø)
...ty/configuration/ConfigurationLoaderSecurity7.java	65.67% <ø> (ø)
...ity/configuration/DlsFilterLevelActionHandler.java	57.20% <ø> (ø)
...rch/security/configuration/DlsFlsRequestValve.java	0.00% <ø> (ø)
...search/security/configuration/DlsFlsValveImpl.java	59.23% <ø> (ø)
...arch/security/dlic/rest/api/AbstractApiAction.java	75.95% <ø> (ø)
...ch/security/dlic/rest/api/FlushCacheApiAction.java	62.50% <ø> (ø)
...earch/security/dlic/rest/api/MigrateApiAction.java	3.66% <ø> (ø)
... and 2 more

... and 2 files with indirect coverage changes

[cwperks]

We may need to manually delete caches for the failing windows checks

[peternied]

Looks like this was required because we've got those Clean up REST API changes in main that haven't been pulled into 2.x [1] - and likely won't until the set of changes is complete.

• [1] Clean up REST API (Part 1) #2900

[peternied]

@cwperks It looks like the codeql build task is broken because of a cached version of the snapshot - should we disable the gradle build cache on our github actions? Is this something we've been doing manually

[cwperks]

@peternied any idea how much disabling caching would slow down the CI? I am in favor of disabling it because it has been making our builds unpredictable.

[peternied]

@cwperks I'll take a slower correct over a fast and incorrect any day. I'll create a PR

[cwperks]

Why is codeql running ./gradlew compileIntegrationTestJava on 2.x?

Task :compileIntegrationTestJava FAILED

https://github.com/opensearch-project/security/actions/runs/5870600207/job/15918932614?pr=3182

Either all integration test changes need to be backport to 2.x from main or this check should not run on 2.x. I would be in support of disabling the check on this branch and only keeping integration tests in main since they are not run as part of CI. We should remove anything integration test code from 2.x.

[peternied]

Why is codeql running ./gradlew compileIntegrationTestJava on 2.x?

@cwperks Good find, can you create an issue and make sure this is all unified between 2.x and main?

[peternied]

@RyanL1997 FYI - I just merged in the change to disable the gradle build cache, we should expect all builds to pass prior to merging.

Note; We don't require codeql. so lets follow up separately