Update doc for decoupling of remote cluster state with remote backed …

…data storage (opensearch-project#6730)

* Update doc for decoupling of remote cluster state with remote backed data storage

Signed-off-by: Sooraj Sinha <soosinha@amazon.com>

* Update _tuning-your-cluster/availability-and-recovery/remote-store/remote-cluster-state.md

Co-authored-by: kolchfa-aws <105444904+kolchfa-aws@users.noreply.github.com>
Signed-off-by: Sooraj Sinha <81695996+soosinha@users.noreply.github.com>

* Update _tuning-your-cluster/availability-and-recovery/remote-store/remote-cluster-state.md

Co-authored-by: kolchfa-aws <105444904+kolchfa-aws@users.noreply.github.com>
Signed-off-by: Sooraj Sinha <81695996+soosinha@users.noreply.github.com>

* Update _tuning-your-cluster/availability-and-recovery/remote-store/remote-cluster-state.md

Co-authored-by: kolchfa-aws <105444904+kolchfa-aws@users.noreply.github.com>
Signed-off-by: Sooraj Sinha <81695996+soosinha@users.noreply.github.com>

* Update _tuning-your-cluster/availability-and-recovery/remote-store/remote-cluster-state.md

Co-authored-by: Nathan Bower <nbower@amazon.com>
Signed-off-by: kolchfa-aws <105444904+kolchfa-aws@users.noreply.github.com>

---------

Signed-off-by: Sooraj Sinha <soosinha@amazon.com>
Signed-off-by: Sooraj Sinha <81695996+soosinha@users.noreply.github.com>
Signed-off-by: kolchfa-aws <105444904+kolchfa-aws@users.noreply.github.com>
Co-authored-by: kolchfa-aws <105444904+kolchfa-aws@users.noreply.github.com>
Co-authored-by: Nathan Bower <nbower@amazon.com>

_tuning-your-cluster/availability-and-recovery/remote-store/remote-cluster-state.md

@@ -24,8 +24,12 @@ _Cluster state_ is an internal data structure that contains the metadata of the
 The cluster state metadata is managed by the elected cluster manager node and is essential for the cluster to properly function. When the cluster loses the majority of the cluster manager nodes permanently, then the cluster may experience data loss because the latest cluster state metadata might not be present in the surviving cluster manager nodes. Persisting the state of all the cluster manager nodes in the cluster to remote-backed storage provides better durability.
 
 When the remote cluster state feature is enabled, the cluster metadata will be published to a remote repository configured in the cluster.
-Any time new cluster manager nodes are launched after disaster recovery, the nodes will automatically bootstrap using the latest metadata stored in the remote repository. 
-After the metadata is restored automatically from the latest metadata stored, and if the data nodes are unchanged in the index data, the metadata lost will be automatically recovered. However, if the data nodes have been replaced, then you can restore the index data by invoking the `_remotestore/_restore` API as described in the [remote store documentation]({{site.url}}{{site.baseurl}}/tuning-your-cluster/availability-and-recovery/remote-store/index/).
+Any time new cluster manager nodes are launched after disaster recovery, the nodes will automatically bootstrap using the latest metadata stored in the remote repository. This provides metadata durability. 
+
+You can enable remote cluster state independently of remote-backed data storage.
+{: .note}
+
+If you require data durability, you must enable remote-backed data storage as described in the [remote store documentation]({{site.url}}{{site.baseurl}}/tuning-your-cluster/availability-and-recovery/remote-store/index/).
 
 ## Configuring the remote cluster state
 
@@ -59,4 +63,3 @@ Setting | Default | Description
 
 The remote cluster state functionality has the following limitations:
 - Unsafe bootstrap scripts cannot be run when the remote cluster state is enabled. When a majority of cluster-manager nodes are lost and the cluster goes down, the user needs to replace any remaining cluster manager nodes and reseed the nodes in order to bootstrap a new cluster.
-- The remote cluster state cannot be enabled without first configuring remote-backed storage.