Re-organize high availability cluster-based deployment docs (#8812)

* Re-organize high availability cluster-based deployment docs

Restructure the HA deployment documentation to match admin workflow:
- Add Preparation section with pre-deployment guidance
- Add Deployment guide section with step-by-step instructions
- Add Next steps section for scaling optimizations
- Preserve Operations and maintenance section for advanced topics
- Emphasize PostgreSQL hot_standby and hot_standby_feedback settings
- Guide admins toward database configuration over config.json

Closes #8811

Co-authored-by: Michael Roberson <roberson-io@users.noreply.github.com>

* Address CodeRabbit and Copilot review feedback

- NFS mounts: switch shared data directory examples from rw,soft,intr to rw,hard
  to prevent partial writes / file corruption during transient NFS outages.
  Drop deprecated intr option (no-op since kernel 2.6.25). Invert the note to
  frame hard as the safe default and soft as a documented availability tradeoff.
- NGINX health checks: rewrite item 6 to accurately describe what max_fails=0
  does (disables passive quarantining), note that per-request failover via
  proxy_next_upstream still works, and direct admins to external active health
  checks against /api/v4/system/ping.
- Fix broken :doc: target deploy-mattermost-on-linux -> deploy-linux.
- Section rename anchor fixes: update the URL fragment in
  enterprise-roll-out-checklist.rst (#proxy-server-configuration ->
  #proxy-server) and the :ref: targets in backing-storage-benchmarks.rst,
  environment-configuration-settings.rst, and manage/statistics.rst to match
  the new "File storage" and "Database" headings.
- PostgreSQL replica/promote commands: replace the hardcoded
  /var/lib/postgresql/data with a DATA_DIR placeholder plus inline
  platform-specific paths (Ubuntu/Debian: /var/lib/postgresql/{version}/main,
  RHEL/CentOS: /var/lib/pgsql/{version}/data). Note that pg_basebackup requires
  the target data directory to be empty.
- Fix UseIpAddress -> UseIPAddress casing for consistency with the canonical
  ClusterSettings.UseIPAddress key used elsewhere in the doc.
- Correct the Amazon RDS / Aurora PostgreSQL configuration claim: both expose
  configuration through DB parameter groups (RDS) and DB cluster parameter
  groups (Aurora).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Fix repeated "availablility" typo in HA database ref labels

Pre-existing typo flagged by CodeRabbit while reviewing the heading-rename
ref-target updates from the previous commit. Three occurrences in the visible
link label of cross-references to the HA deployment docs.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Add replica sync check before manual failover promotion

Promoting a replica that hasn't caught up with the primary loses any
unreplayed WAL, so the procedure now verifies replication status first.

---------

Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>
Co-authored-by: Michael Roberson <roberson-io@users.noreply.github.com>
Co-authored-by: Katie Wiersgalla <39744472+wiersgallak@users.noreply.github.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Sven Hüster <sven@mattermost.com>

Author: 5 people

source/administration-guide/configure/environment-configuration-settings.rst

@@ -786,7 +786,7 @@ AWS High Availablity RDS cluster deployments
 
 For an AWS High Availability RDS cluster deployment, point this configuration setting to the write/read endpoint at the **cluster**
 level to benefit from the AWS failover handling. AWS takes care of promoting different database nodes to be the writer node.
-Mattermost doesn't need to manage this. See the :ref:`high availablility database configuration <administration-guide/scale/high-availability-cluster-based-deployment:database configuration>` documentation for details.
+Mattermost doesn't need to manage this. See the :ref:`high availability database configuration <administration-guide/scale/high-availability-cluster-based-deployment:database>` documentation for details.
 
 .. config:setting:: maximum-open-connections
   :displayname: Maximum open connections (Database)
@@ -1042,7 +1042,7 @@ Read replicas
 AWS High Availability RDS cluster deployments
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-For an AWS High Availability RDS cluster deployment, point this configuration setting directly to the underlying read-only node endpoint within the RDS cluster to circumvent the failover/load balancing that AWS/RDS takes care of (except for the write traffic). Mattermost has its own method of balancing the read-only connections and can also balance those queries to the data source/write+read connection should those nodes fail. See the :ref:`high availablility database configuration <administration-guide/scale/high-availability-cluster-based-deployment:database configuration>` documentation for details.
+For an AWS High Availability RDS cluster deployment, point this configuration setting directly to the underlying read-only node endpoint within the RDS cluster to circumvent the failover/load balancing that AWS/RDS takes care of (except for the write traffic). Mattermost has its own method of balancing the read-only connections and can also balance those queries to the data source/write+read connection should those nodes fail. See the :ref:`high availability database configuration <administration-guide/scale/high-availability-cluster-based-deployment:database>` documentation for details.
 
 .. config:setting:: search-replicas
   :displayname: Search replicas (Database)
@@ -1070,7 +1070,7 @@ Search replicas
 AWS High Availability RDS cluster deployments
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-For an AWS High Availability RDS cluster deployment, point this configuration setting directly to the underlying read-only node endpoint within the RDS cluster to circumvent the failover/load balancing that AWS/RDS takes care of (except for the write traffic). Mattermost has its own method of balancing the read-only connections and can also balance those queries to the data source/write+read connection should those nodes fail. See the :ref:`high availablility database configuration <administration-guide/scale/high-availability-cluster-based-deployment:database configuration>` documentation for details.
+For an AWS High Availability RDS cluster deployment, point this configuration setting directly to the underlying read-only node endpoint within the RDS cluster to circumvent the failover/load balancing that AWS/RDS takes care of (except for the write traffic). Mattermost has its own method of balancing the read-only connections and can also balance those queries to the data source/write+read connection should those nodes fail. See the :ref:`high availability database configuration <administration-guide/scale/high-availability-cluster-based-deployment:database>` documentation for details.
 
 .. config:setting:: replica-lag-settings
   :displayname: Replica lag settings (Database)

source/administration-guide/manage/statistics.rst

@@ -74,7 +74,7 @@ Master DB Conns
     The number of active connections currently on your master database.
 
 Replica DB Conns
-    The number of active connections currently on one or more of :ref:`your read replica databases <administration-guide/scale/high-availability-cluster-based-deployment:database configuration>`.
+    The number of active connections currently on one or more of :ref:`your read replica databases <administration-guide/scale/high-availability-cluster-based-deployment:database>`.
 
 Total Playbooks
     The total number of collaborative playbooks on this server.

source/administration-guide/scale/backing-storage-benchmarks.rst

@@ -73,7 +73,7 @@ Testing notes
 
 - For S3 tests, :ref:`Amazon S3 exported upload part size <administration-guide/configure/environment-configuration-settings:amazon s3 upload part size>` was set to the default value (100MB).
 - Local EBS storage is the stock gp3 (3000 IOPS) provided by EC2 instances.
-- Both EBS and EFS solutions tested are considered ``local`` storage options from the application's perspective, where the :ref:`file storage system <administration-guide/configure/environment-configuration-settings:file storage system>` is set to ``local`` in both cases. EFS is essentially AWS's managed NFS, which enables it to serve as a potential alternative to S3 by allowing multiple Mattermost nodes in a high-availability (HA) deployment to share a common file system. In such HA scenarios, the standard local file storage (e.g., an EBS volume attached to a single instance) :ref:`is not suitable, as it can't be shared across multiple nodes <administration-guide/scale/high-availability-cluster-based-deployment:file storage configuration>`. EFS is a good alternative in this case, but EFS is not a block storage solution like EBS.
+- Both EBS and EFS solutions tested are considered ``local`` storage options from the application's perspective, where the :ref:`file storage system <administration-guide/configure/environment-configuration-settings:file storage system>` is set to ``local`` in both cases. EFS is essentially AWS's managed NFS, which enables it to serve as a potential alternative to S3 by allowing multiple Mattermost nodes in a high-availability (HA) deployment to share a common file system. In such HA scenarios, the standard local file storage (e.g., an EBS volume attached to a single instance) :ref:`is not suitable, as it can't be shared across multiple nodes <administration-guide/scale/high-availability-cluster-based-deployment:file storage>`. EFS is a good alternative in this case, but EFS is not a block storage solution like EBS.
 
 
 Supported storage options