Implement new extension points in IdentityPlugin and add ContextProvidingPluginSubject

[cwperks]

Description

Re-opening this previously closed PR to rebase on top of Optimized Privilege Evaluation

Companion PR in core: opensearch-project/OpenSearch#14630

This PR by itself does not add additional functionality, it simply implements the new extension points in core and introduces a new class called ContextProvidingPluginSubject which populates a header in the ThreadContext with the canonical class name of the plugin that is executing code using pluginSystemSubject.runAs(() -> { ... }). See ./gradlew integrationTest --tests SystemIndexTests for an example that verifies that a block of code run with pluginSystemSubject.runAs(() -> { ... }) has contextual info in the thread context.

• Category (Enhancement, New feature, Bug fix, Test fix, Refactoring, Maintenance, Documentation)

Enhancement

Issues Resolved

Related to #4439

Check List

• New functionality includes testing
• New functionality has been documented
• New Roles/Permissions have a corresponding security dashboards plugin PR
• API changes companion pull request created
• 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

Attention: Patch coverage is 84.52381% with 13 lines in your changes missing coverage. Please review.

Project coverage is 71.48%. Comparing base (4aa7b1c) to head (c25e1ab).

Files with missing lines	Patch %	Lines
...ensearch/security/privileges/ActionPrivileges.java	63.63%	5 Missing and 3 partials ⚠️
...earch/security/identity/PluginContextSwitcher.java	71.42%	2 Missing ⚠️
...ava/org/opensearch/security/auth/SecurityUser.java	90.00%	1 Missing ⚠️
...ecurity/privileges/SystemIndexAccessEvaluator.java	92.85%	0 Missing and 1 partial ⚠️
...c/main/java/org/opensearch/security/user/User.java	0.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4896      +/-   ##
==========================================
+ Coverage   71.41%   71.48%   +0.06%     
==========================================
  Files         334      337       +3     
  Lines       22515    22595      +80     
  Branches     3585     3596      +11     
==========================================
+ Hits        16080    16151      +71     
- Misses       4643     4648       +5     
- Partials     1792     1796       +4     

Files with missing lines	Coverage Δ
.../opensearch/security/OpenSearchSecurityPlugin.java	84.37% <100.00%> (+0.36%)	⬆️
.../org/opensearch/security/auth/BackendRegistry.java	78.52% <100.00%> (+0.47%)	⬆️
...org/opensearch/security/filter/SecurityFilter.java	66.66% <100.00%> (+0.78%)	⬆️
...curity/identity/ContextProvidingPluginSubject.java	100.00% <100.00%> (ø)
...earch/security/privileges/PrivilegesEvaluator.java	73.96% <100.00%> (+0.31%)	⬆️
...g/opensearch/security/support/ConfigConstants.java	95.23% <ø> (ø)
...ava/org/opensearch/security/auth/SecurityUser.java	90.00% <90.00%> (ø)
...ecurity/privileges/SystemIndexAccessEvaluator.java	76.92% <92.85%> (+1.72%)	⬆️
...c/main/java/org/opensearch/security/user/User.java	69.41% <0.00%> (-0.83%)	⬇️
...earch/security/identity/PluginContextSwitcher.java	71.42% <71.42%> (ø)
... and 1 more

... and 2 files with indirect coverage changes

[nibix]

In what life-cycle stage(s) will this method will be called in?

In the current state of the implementation, this method must be called very early, as the constructed ActionPrivileges instance is immutable and will be only updated upon configuration change events. If this method gets called at the wrong time, changes won't be picked up immediately.

Additionaly, an open question is whether one has to think of concurrent calls or not.

[nibix]

Nit: This method name uses Action (singular), while the called method name uses Actions (plural)

[nibix]

I guess, it is only a temporary state that we'll have cluster actions here?

If we get also index privileges and possibly other stuff soon, this certainly would deserve its own class encapsulating and managing the details. Then, one could also avoid this call delegation of updatePluginToClusterActions() through SecurityFilter which feels artificial.