[Resource Sharing] Adds a Share API to fetch and update sharing information

[DarshitChanpura]

Description

Adds a new /share API to support sharing of resources by dashboard component. It supports three methods:

1. GET /_plugins/_security/api/resource/share - requires two query params ?resource_id=<id>&resource_type=<name> to be present.
   1. fetches the current sharing information for the requested resource
2. PUT /_plugins/_security/api/resource/share

{
  "resource_id": "%s",
  "resource_type": "%s",
  "share_with": {
    "%s" : {
        "users": ["%s"]
    }
  }
}

1. Creates or update (overrides) any existing sharing information.
2. PATCH /_plugins/_security/api/resource/share

{
  "resource_id": "%s",
  "resource_type": "%s",
  "add": {
    %s
  },
  "revoke": {
    %s
  }
}

1. Patches existing sharing info:
   1. add block contains information of entities and levels at which to share
   2. revoke block contains information of entities and levels at which to revoke

The structure for PUT and PATCH request content' sharing block must look like:

 {
    "READ_ONLY": {
      "users": ["user1", "user2"],
      "roles": ["viewer_role"],
      "backend_roles": ["data_analyst"]
    },
    "READ_WRITE": {
      "users": ["admin_user"],
      "roles": ["editor_role"],
      "backend_roles": ["content_manager"]
    }
  }

• Category - Enhancement
• Why these changes are required?
  • Sets up base for future dashboard component to directly invoke share apis when loading and updating sharing info.

Issues Resolved

TBD

Do these changes introduce new permission(s) to be displayed in the static dropdown on the front-end? If so, please open a draft PR in the security dashboards plugin and link the draft PR here
TBD

Testing

Integration testing

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.

[DarshitChanpura]

This PR has changes from #5408 and hence that PR must be reviewed prior to reviewing this one.

[codecov]

Codecov Report

❌ Patch coverage is 77.39130% with 52 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.94%. Comparing base (25fe5f8) to head (3445693).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
...rch/security/resources/api/share/ShareRequest.java	65.33%	22 Missing and 4 partials ⚠️
...arch/security/resources/ResourceAccessHandler.java	78.12%	7 Missing ⚠️
...ch/security/resources/api/share/ShareResponse.java	50.00%	6 Missing ⚠️
...ecurity/resources/ResourceSharingIndexHandler.java	82.75%	3 Missing and 2 partials ⚠️
...arch/security/spi/resources/sharing/ShareWith.java	86.36%	1 Missing and 2 partials ⚠️
...h/security/privileges/ResourceAccessEvaluator.java	0.00%	2 Missing ⚠️
.../security/resources/api/share/ShareRestAction.java	92.30%	1 Missing and 1 partial ⚠️
...rity/resources/api/share/ShareTransportAction.java	94.11%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5459      +/-   ##
==========================================
+ Coverage   72.88%   72.94%   +0.06%     
==========================================
  Files         400      405       +5     
  Lines       24935    25157     +222     
  Branches     3806     3829      +23     
==========================================
+ Hits        18173    18351     +178     
- Misses       4912     4947      +35     
- Partials     1850     1859       +9     

Files with missing lines	Coverage Δ
...rch/security/spi/resources/sharing/Recipients.java	75.55% <100.00%> (+0.55%)	⬆️
.../opensearch/security/OpenSearchSecurityPlugin.java	85.07% <100.00%> (+0.09%)	⬆️
...g/opensearch/security/dlic/rest/support/Utils.java	58.66% <ø> (ø)
...arch/security/resources/api/share/ShareAction.java	100.00% <100.00%> (ø)
...rity/resources/api/share/ShareTransportAction.java	94.11% <94.11%> (ø)
...h/security/privileges/ResourceAccessEvaluator.java	67.85% <0.00%> (ø)
.../security/resources/api/share/ShareRestAction.java	92.30% <92.30%> (ø)
...arch/security/spi/resources/sharing/ShareWith.java	75.43% <86.36%> (+6.86%)	⬆️
...ecurity/resources/ResourceSharingIndexHandler.java	71.80% <82.75%> (+1.34%)	⬆️
...ch/security/resources/api/share/ShareResponse.java	50.00% <50.00%> (ø)
... and 2 more

... and 7 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[DarshitChanpura]

@DarshitChanpura for public facing APIs I think we should use resource_type instead of resource_index as resource_type is a proxy for the index and meant to be a human readable name for that type of sharable resource. We can support resource_index, but let's make sure to extend this and support type as well.

This API will mostly be called by dashboards and REST clients. We have thus far used notion of resource-index everywhere. I'm not too opinionated on resource-index but I think it makes more sense as it strictly ties with the index where the resource is stored.

[cwperks]

Can we always have this return empty if not present and move null handling to within add() and revoke().

[cwperks]

I think you could also avoid re-assigning this variable and have the updates occur in-place.

[DarshitChanpura]

It should be fine here. No point in creating and returning empty object if not shareWith exists.