Backport/2.16

[KishoreKicha14]

Description

[Describe what this change achieves]

• Category (Enhancement, New feature, Bug fix, Test fix, Refactoring, Maintenance, Documentation)
• Why these changes are required?
• What is the old behavior before changes and new behavior after changes?

Issues Resolved

[List any issues this PR will resolve]

Is this a backport? If so, please add backport PR # and/or commits #, and remove backport-failed label from the original PR.

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

Testing

[Please provide details of testing done: unit testing, integration testing and manual 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.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🧪 PR contains tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ Recommended focus areas for review Resource Leak The StoredContext returned by contextToRestore.get() at line 385 is not closed. This leaks the context resource. The supplier creates a new StoredContext each time get() is called, and without closing it, the context is never properly released. This occurs on every successful response handling. contextToRestore.get();

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Close StoredContext to prevent leak The contextToRestore.get() call in handleResponse() retrieves a StoredContext but doesn't close it, causing a resource leak. The context should be used in a try-with-resources block to ensure proper cleanup. src/main/java/org/opensearch/security/transport/SecurityInterceptor.java [385] -contextToRestore.get(); +try (ThreadContext.StoredContext ignore = contextToRestore.get()) { + // existing code continues here +} Suggestion importance[1-10]: 10 __ Why: The contextToRestore.get() call retrieves a StoredContext without closing it, causing a critical resource leak. The PR already fixes this issue in handleException() (line 416) using try-with-resources, but handleResponse() is missing this fix, making this a high-priority bug.	High