Docs: Improve upgrade and installation documentation structure for multi-node and Cloud Native deployments

Problem to solve

The current upgrade and installation documentation is primarily focused on single-node deployments, without as much focus for users running more complex GitLab environments. There are several structural issues:

Affected documentation:

• https://docs.gitlab.com/update/ (upgrade documentation)
• https://docs.gitlab.com/install/ (installation documentation)
• https://docs.gitlab.com/charts/installation/upgrade/
• https://docs.gitlab.com/operator/gitlab_upgrades/

Specific problems:

1. The upgrade flow doesn't clearly define upgrade journey based on GitLab deployment architecture (single Omnibus, multi-node Omnibus, Cloud Native ) rather than distribution method upgrades (Omnibus, Chart, Operator) where latter docs more focused on single node installations

2. Chart/Operator documentation focuses on default Helm chart deployments, but Cloud Native Hybrid and Cloud Native Services are the only supported production deployment method.

3. Multi-node upgrade documentation isn't linked from Chart/Operator upgrade pages, even though it's applicable to Cloud Native deployments.

Further details

Users running production GitLab deployments need clear guidance for:

• Upgrade process for customer specific architecture
• Cloud Native architectures with various combinations:
  • Cloud native hybrid: GitLab Chart/Operator + Omnibus stateful services / external cloud services (RDS, ElastiCache) + Omnibus Gitaly Cluster
  • Cloud native services: GitLab Chart/Operator (with Gitaly Sharded in K8s) + external cloud services

Proposal

Restructure upgrade and installation documentation with a clearer hierarchy:

a) General pre-upgrade considerations (common to all deployment types)

• Backup procedures
• Upgrade path planning
• Health checks

b) Upgrade path selection based on architecture:

• Single-node deployments:
  • Linux package (Omnibus)
  • Docker
  • Self-compiled
• Multi-node deployments with downtime:
  • Multi-node Omnibus
  • Cloud Native Hybrid (Omnibus + CN components)
  • Cloud Native Services (cloud services + CN)
• Multi-node deployments with zero downtime:
  • Multi-node Omnibus
  • Cloud Native Hybrid (once available)

c) Common post-upgrade steps

• Verification procedures
• Rollback guidance
• Troubleshooting

Specific improvements:

1. Create doc structure for selecting appropriate upgrade documentation
2. Cross-link Chart/Operator upgrade pages to multi-node upgrade documentation
3. Cross-link ZDU for Cloud Native deployments once it's available
4. Consider similar structural improvements to installation documentation
5. Consider Geo relevant cross-links

• Related MR: Refine upgrade instructions for installation me... (!209230)