Relax the join validation for Remote State publication

[rajiv-kv]

Description

[Describe what this change achieves]
For Remote Store clusters, there is validation which ensures that remote attributes are either present / absent in all the nodes in cluster. However for clusters where only remote publication is enabled, this need not be enforced. ClusterManager ensures that the remote connecting node has publication enabled before publishing cluster-state updates[#15216 ]. Incase the remote node does not have publication enabled, it falls back to publish the cluster-state via transport

Related Issues

Resolves #[Issue number to be closed when this PR is merged]

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 366e344: 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?

[github-actions]

❌ Gradle check result for 15ff668: 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?

[github-actions]

❌ Gradle check result for 6d0cb37: 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?

[github-actions]

❌ Gradle check result for 46da900: null

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 result for 48a5373: 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?

[Bukhtawar]

Just to understand the strategy better, are we saying that based on the destination node we decide whether the publication needs to be remote vs local transport at the time of publication?

This is not deciding publication strategy but rather letting node join the cluster when remote state/ publication is enabled but store is disabled by validation desired repos at the time of node join.

Yes this was mostly to clarify

Incase the remote node does not have publication enabled, it falls back to publish the cluster-state via transport

[github-actions]

✅ Gradle check result for 802d861: SUCCESS

[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-15471-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 2793634f98819029e3bee327e1a47a89f8acc580
# Push it to GitHub
git push --set-upstream origin backport/backport-15471-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-15471-to-2.x.