[Remote State] Upload incremental cluster state on master re-election

[shiv0408]

Description

Currently we upload full cluster state when master re-election happens. This can lead to un-neccessary upload of cluster state attributes even if no change is there in the cluster state attributes. If the cluster has lots of indices or other state metadata. Uploading state every time a node is trying to get elected as cluster manager, the overhead of uploading the cluster state can be big and can problems like S3 throttling or election loop.

Also, when we receive a publication request on a node where the Remote Publication is marked as enabled, but the publication is from Transport channel, we reset the last accepted state and manifest in our RemotePersistedState object to avoid any stale value being persisted on the nodes. Now if these nodes try to become cluster manager, they will be uploading the full state, which rather than uploading a diff from stale state.

Related Issues

Resolves #10682

Check List

• Functionality includes testing.
• API changes companion pull request created, if applicable.
• Public documentation issue/PR created, if applicable.

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 result for 9710a15: FAILURE

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?

[shiv0408]

❌ Gradle check result for 4b4b8b3: FAILURE

org.opensearch.cluster.MinimumClusterManagerNodesIT.testThreeNodesNoClusterManagerBlock - #14289

[github-actions]

❕ Gradle check result for 4b4b8b3: UNSTABLE

Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

[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:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/OpenSearch/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch/backport-2.x
# Create a new branch
git switch --create backport/backport-15145-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 cbdcbb7da3d87fdccfca164ac8f6914a55dc19cb
# Push it to GitHub
git push --set-upstream origin backport/backport-15145-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-15145-to-2.x.

[opensearch-trigger-bot]

The backport to 2.17 failed:

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

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/OpenSearch/backport-2.17 2.17
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch/backport-2.17
# Create a new branch
git switch --create backport/backport-15145-to-2.17
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 cbdcbb7da3d87fdccfca164ac8f6914a55dc19cb
# Push it to GitHub
git push --set-upstream origin backport/backport-15145-to-2.17
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch/backport-2.17

Then, create a pull request where the base branch is 2.17 and the compare/head branch is backport/backport-15145-to-2.17.