Use ExtensionsManager.lookupExtensionSettingsById when verifying extension unique id

[cwperks]

Description

The current method being used to permit handshake requests from extensions is failing because an extension with the unique id is not present in the map of initialized extensions. Since the handshake is the first request performed to initialize an extension, the extension will not be available in the map of initialized extensions. This PR consumes a new method defined in core to get extension settings by unique id which checks to see if the extension unique id is present in the list of extensions in extensions/extensions.yml

Associated PR in core: opensearch-project/OpenSearch#7466

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

Bug fix

Issues Resolved

#2747

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.

[saratvemulapalli]

Curious what settings of extensions is security plugin interested in ?

[cwperks]

@saratvemulapalli There are a couple of instances where security would like to "extend" the settings in extensions.yml similar to how ActionPlugin.getSettings() works for extending opensearch where plugins can add settings that would be placed in opensearch.yml. Is it right to treat extensions/extensions.yml as static settings for each installed extension and compare it to opensearch.yml?

See this issue for 2 examples of settings that security would like to add and read from extensions.yml: #2746

[saratvemulapalli]

@saratvemulapalli There are a couple of instances where security would like to "extend" the settings in extensions.yml similar to how ActionPlugin.getSettings() works for extending opensearch where plugins can add settings that would be placed in opensearch.yml. Is it right to treat extensions/extensions.yml as static settings for each installed extension and compare it to opensearch.yml?

See this issue for 2 examples of settings that security would like to add and read from extensions.yml: #2746

Thanks @cwperks. It makes sense to read information. I have few questions on writing to extensions.yml, we can continue to converse on: #2746

[peternied]

BWC tests are blocked on failing CI because 2.x branch needs this fix backported to it as well. I will bypass these tests and merge if everything else passed so this change can be backported to unblock all branches.

[codecov-commenter]

Codecov Report

Merging #2749 (14f973c) into main (54d47ab) will not change coverage.
The diff coverage is 0.00%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@            Coverage Diff            @@
##               main    #2749   +/-   ##
=========================================
  Coverage     61.36%   61.36%           
- Complexity     3413     3414    +1     
=========================================
  Files           272      272           
  Lines         18850    18850           
  Branches       3296     3296           
=========================================
  Hits          11568    11568           
  Misses         5684     5684           
  Partials       1598     1598           

Impacted Files	Coverage Δ
...rch/security/transport/SecurityRequestHandler.java	63.70% <0.00%> (ø)

[opensearch-trigger-bot]

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 1

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
cd .worktrees/backport-2.x
# Create a new branch
git switch --create backport/backport-2749-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 9d758f9166e6af76589ab403a6ee5ec22792bc64
# Push it to GitHub
git push --set-upstream origin backport/backport-2749-to-2.x
# Go back to the original working tree
cd ../..
# 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-2749-to-2.x.