Create concept of persistent ThreadContext headers that are unstashable

[cwperks]

Description

This PR introduces the concept of "persistent" ThreadContext headers modeled after transient headers. These headers perform exactly the same as ThreadContext headers, but are not stashable and will always be available even inside a block where the ThreadContext has been stashed.

Some additional context on the ThreadContext:

The values in the ThreadContext are immutable after they have already been written to once. If a caller tries to overwrite an existing ThreadContext header than the caller will receive an IllegalArgumentException.

Related Issues

Resolves opensearch-project/security#2909

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Commits are signed per the DCO using --signoff
• Commit changes are listed out in CHANGELOG.md file (See: Changelog)

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]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/18475/
• CommitID: 948e611
  Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
  Is the failure a flaky test unrelated to your change?

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/18477/
• CommitID: 6d65d28
  Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
  Is the failure a flaky test unrelated to your change?

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/18478/
• CommitID: 34b14fd
  Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
  Is the failure a flaky test unrelated to your change?

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: UNSTABLE ❕
• TEST FAILURES:

      1 org.opensearch.remotestore.SegmentReplicationUsingRemoteStoreIT.testNodeDropWithOngoingReplication

• URL: https://build.ci.opensearch.org/job/gradle-check/18614/
• CommitID: 8a28d12
  Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: UNSTABLE ❕
• TEST FAILURES:

      2 org.opensearch.index.shard.RemoteStoreRefreshListenerTests.classMethod
      1 org.opensearch.remotestore.SegmentReplicationUsingRemoteStoreIT.testNodeDropWithOngoingReplication
      1 org.opensearch.index.shard.RemoteStoreRefreshListenerTests.testRefreshSuccessAfterFailureInFirstAttemptAfterSnapshotAndMetadataUpload

• URL: https://build.ci.opensearch.org/job/gradle-check/18616/
• CommitID: 8ef81ca
  Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

[reta]

@dblock @andrross any concerns folks?

[peternied]

This PR is building up features around stashing context, what about eliminating the need for plugins to access this API, what would that take?

This feature adds overhead in latency/bandwidth to every transport request without providing a better security implementation in the short term.

[cwperks]

This PR is building up features around stashing context, what about eliminating the need for plugins to access this API, what would that take?

@peternied One assurance that plugins cannot read from the persistent headers is that if an object is stored there that is only known to the plugin and no other plugins (i.e. the Security User object), then other plugins cannot read it since their classloaders don't have access to the Security User object.

I am also looking at a more JSM style approach, or similar, that would let only the IdentityPlugin utilize the ThreadContext and no other plugins. Or making it more targeted and forbidding accessing certain headers or areas of the ThreadContext.

This feature adds overhead in latency/bandwidth to every transport request without providing a better security implementation in the short term.

I have not measured that, but I don't anticipate a hit to performance by storing the authenticated user as a persistent header (not currently implemented yet in the security plugin). I will try to gather data on that, but the impact should be marginal.

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: UNSTABLE ❕
• TEST FAILURES:

      1 org.opensearch.remotestore.SegmentReplicationUsingRemoteStoreIT.testNodeDropWithOngoingReplication

• URL: https://build.ci.opensearch.org/job/gradle-check/18811/
• CommitID: 9f1a668
  Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

[dblock]

I don't see any problems here. @peternied do you have strong objections to merging this?

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/19307/
• CommitID: 776ab03
  Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green.
  Is the failure a flaky test unrelated to your change?

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: UNSTABLE ❕
• TEST FAILURES:

      1 org.opensearch.remotestore.RemoteStoreIT.testStaleCommitDeletionWithoutInvokeFlush
      1 org.opensearch.index.shard.RemoteStoreRefreshListenerTests.testRefreshSuccessOnThirdAttemptAttempt
      1 org.opensearch.gateway.RecoveryFromGatewayIT.testReuseInFileBasedPeerRecovery
      1 org.opensearch.cluster.allocation.AwarenessAllocationIT.testThreeZoneOneReplicaWithForceZoneValueAndLoadAwareness
      1 org.opensearch.aliases.IndexAliasesIT.testSameAlias

• URL: https://build.ci.opensearch.org/job/gradle-check/19308/
• CommitID: f434b31
  Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

[peternied]

End of the day we've got the performance testing requirements pre-release and we can use that to detect issues, lets lean on those instead of trying to micro-optimize/analyze in this scenario.

Lets merge this and keep iteration - thanks for the contribution @cwperks

[opensearch-trigger-bot]

The backport to 2.x failed:

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

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

[dblock]

will need a manual backport, as usual

[cwperks]

Creating a manual backport now

[cwperks]

@dblock Created backport PR: #8507