docs: cluster peering documentation improvements

[boruszak]

Description

This PR was created in response to feedback from Support. They reported some difficulty determining the required steps to set up cluster peering connections. Edits have been made to streamline this information and avoid endless link loops between pages.

This PR also suggests a naming best practice for cluster peers. The <datacenter>-<partition> format creates a human-readable configuration pattern that simplifies peer management.

Deployment previews

VMs:

• Cluster peering overview
• Cluster peering best practices
• Establish cluster peering connections
• Manage cluster peering connections
• Manage L7 traffic with cluster peering connections
• Create sameness groups

K8s:

• Cluster peering on Kubernetes best practices
• Establish cluster peering connections on Kubernetes
• Manage cluster peering connections on Kubernetes
• Manage L7 traffic for cluster peering connections on Kubernetes
• Create sameness groups on Kubernetes

PR Checklist

• updated test coverage
• external facing docs updated
• appropriate backport labels added
• not a security concern

[krastin]

I wanted to draw the attention on whether you have considered explicitly calling out the admin partition parameter; the rest is just tiny typos. The cluster peering docs are looking great!

[krastin]

Should we explicitly include the Partition parameter in here and all related sections? I believe it's better safe than sorry but i'm not sure if Consul CE will complain about the parameter.

[krastin]

Suggested change

	1. Create a configuration entry and specify the `Kind` as `"exported-services"`. The following example exports services between `default` admin partitions. To export services between non-default admin partitions, you must include a `"Partition"` filed that contains the name of the local partition the configuration entry applies to.
	1. Create a configuration entry and specify the `Kind` as `"exported-services"`. The following example exports services between `default` admin partitions. To export services between non-default admin partitions, you must include a `"Partition"` field that contains the name of the local partition the configuration entry applies to.

[krastin]

Suggested change

1. Add the `"consul.hashicorp.com/connect-inject": "true"` annotation to your service's pods before deploying the workload so that the services in `cluster-01` can dial `backend` in `cluster-02`. To dial the upstream service from an application, configure the application so that that requests are sent to the correct DNS name as specified in [Service Virtual IP Lookups](/consul/docs/services/discovery/dns-static-lookups#service-virtual-ip-lookups). The following example highlights the annotation that allows the workload to join the mesh and dial the upstream service using the correct DNS name. For more information about formatting a DNS name that includes namespaces or parrtitions, refer to [Service Virtual IP Lookups for Consul Enterprise](/consul/docs/services/discovery/dns-static-lookups#service-virtual-ip-lookups-for-consul-enterprise).

1. Add the `"consul.hashicorp.com/connect-inject": "true"` annotation to your service's pods before deploying the workload so that the services in `cluster-01` can dial `backend` in `cluster-02`. To dial the upstream service from an application, configure the application so that that requests are sent to the correct DNS name as specified in [Service Virtual IP Lookups](/consul/docs/services/discovery/dns-static-lookups#service-virtual-ip-lookups). The following example highlights the annotation that allows the workload to join the mesh and dial the upstream service using the correct DNS name. For more information about formatting a DNS name that includes namespaces or partitions, refer to [Service Virtual IP Lookups for Consul Enterprise](/consul/docs/services/discovery/dns-static-lookups#service-virtual-ip-lookups-for-consul-enterprise).