[Remote Clusters] Connection modes and Security models presented in their own pages for all deployment types

[eedugon]

This PR presents RCS connection modes (proxy & sniff) and security models (TLS certificates & API key) properly within Remote Clusters sections, as currently the detailed information was only available in the self-managed configuration guide for remote clusters.

Pending items after validating the content:

• Update links in other docs-content content (and other repos) to these new docs instead of the self-managed configuration guides.

• After Remote clusters client settings moved from docs-content elasticsearch#135698 we can link to the ref docs for settings instead of the self-managed doc.

• As soon as we merge these new docs (or maybe in this PR also) we will analyze if the self-managed docs can be updated as they might feel repetitive / duplicate. Maybe we can use snippets and then enrich the self-managed content.

Closes #2064

[github-actions]

🔍 Preview links for changed docs

• deploy-manage/remote-clusters/connection-modes.md
• deploy-manage/remote-clusters/security-models.md
• deploy-manage/remote-clusters.md

[shainaraskas]

generally looks really good. only have style comments really

one question: where did you source this information? is it duplicated somewhere where we should remove it and point to this as the official source of truth?

[shainaraskas]

nit: this doesn't really flow nicely because you're also explaining what the models and modes are in this list. I'd probably kill this sentence and just leave the links as implicit.

[shainaraskas]

Reading through this, I feel like this should maybe just be labeled as self: ga + MAYBE eck: ga with a note that ece/ech use proxy mode under the hood.

otherwise just label it stack because it's info relevant to all stack-managed deployments

[shainaraskas]

sometimes people refer to ece/eck as "self-managed environments" so this is a tiny bit clearer

Suggested change

- **Self-managed environments:** If direct connections on the publish addresses between {{es}} nodes in both clusters are possible, you can use sniff mode. If direct connectivity is difficult to implement—for example, when clusters are separated by NAT, firewalls, or containerized environments—you can place a reverse proxy or load balancer in front of the remote cluster and use proxy mode instead.

- **Self-managed clusters:** If direct connections on the publish addresses between {{es}} nodes in both clusters are possible, you can use sniff mode. If direct connectivity is difficult to implement—for example, when clusters are separated by NAT, firewalls, or containerized environments—you can place a reverse proxy or load balancer in front of the remote cluster and use proxy mode instead.

[shainaraskas]

Suggested change

	# Remote clusters connection modes
	# Remote cluster connection modes

[shainaraskas]

Suggested change

	The sniff mode is not supported in {{ech}} and {{ece}} deployments, and it's not recommended in {{eck}} due to its complexity. Use proxy mode instead.
	Sniff mode is not supported in {{ech}} and {{ece}} deployments. In {{eck}}, sniff mode is not recommended due to its complexity. In these three cases, use proxy mode instead.

[shainaraskas]

avoid and/or - we can use an "inclusive or"

Suggested change

* All cross-cluster requests from the local cluster are bound by the API key’s privileges, regardless of local users associated with the requests. For example, if the API key only allows read access to `my-index` on the remote cluster, even a superuser from the local cluster is limited by this constraint. This mechanism enables the remote cluster’s administrator to have full control over who can access what data with cross-cluster search and/or cross-cluster replication. The remote cluster’s administrator can be confident that no access is possible beyond what is explicitly assigned to the API key.

* All cross-cluster requests from the local cluster are bound by the API key’s privileges, regardless of local users associated with the requests. For example, if the API key only allows read access to `my-index` on the remote cluster, even a superuser from the local cluster is limited by this constraint. This mechanism enables the remote cluster’s administrator to have full control over who can access what data with cross-cluster search or cross-cluster replication. The remote cluster’s administrator can be confident that no access is possible beyond what is explicitly assigned to the API key.

[shainaraskas]

Suggested change

* On the local cluster side, not every local user needs to access every piece of data allowed by the API key. An administrator of the local cluster can further configure additional permission constraints on local users so each user only gets access to the necessary remote data. Note it is only possible to further reduce the permissions allowed by the API key for individual local users. It is impossible to increase the permissions to go beyond what is allowed by the API key.

* On the local cluster side, not every local user needs to access every piece of data allowed by the API key. An administrator of the local cluster can further configure additional permission constraints on local users so each user only gets access to the necessary remote data. It is only possible to further reduce the permissions allowed by the API key for individual local users. It is impossible to increase the permissions to go beyond what is allowed by the API key.

[shainaraskas]

while these brackets make sense, we technically should not use them

Suggested change

	In this model, cross-cluster operations use [a dedicated server port](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md#remote_cluster.port) (remote cluster interface), for communication between clusters. The default port is `9443`. The remote cluster must enable this port for local clusters to connect.
	In this model, cross-cluster operations use [a dedicated server port](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md#remote_cluster.port), referred to as the remote cluster interface, for communication between clusters. The default port is `9443`. The remote cluster must enable this port for local clusters to connect.

[shainaraskas]

each setup can be thought of on a one-to-one basis, so we should always make this singular except for when we refer to the concept as a whole

Suggested change

	Refer to [Remote clusters setup](../remote-clusters.md#setup) for configuration guidance across all deployment types.
	Refer to [Remote cluster setup](../remote-clusters.md#setup) for configuration guidance across all deployment types.

[shainaraskas]

Suggested change

	Refer to [Remote clusters setup](../remote-clusters.md#setup) for configuration guidance across all deployment types.
	Refer to [Remote cluster setup](../remote-clusters.md#setup) for configuration guidance across all deployment types.