Certify the 5K user reference architecture in the docs

What does this MR do?

This MR removes the WIP status of the 5k architecture from the documentation and certifies it.

I'm seeking an explicit approval on this MR from ~"Self-managed Scalability Working Group" members to ensure we've got sign off on this being the architecture we move forward with for now. In the future it may be iterated as we continue testing and learning more.

Related issues

Closes gitlab-org/quality/performance#126 (closed)

Summary of past/current discussion points

• Should we include notes about Geo in the documentation?
  • Yes, absolutely. We don't consider this a blocker for certifying the reference architecture, though. We have an issue to add it.
  • gitlab-org/quality/performance#18 (moved)

.

• Should Redis and Sentinel be co-located on the same nodes?
  • Probably not. We don't consider this a blocker for certifying the reference architecture, though. We have an issue to separate them.
  • gitlab-org/quality/performance#156 (closed)

.

• Are we using SSDs or HDDs?
  • This architecture was originally created with HDDs, but we are in the process of flipping that over to SSD. We don't consider this a blocker for certifying the reference architecture, though. We have an issue to change them.
  • gitlab-org/quality/performance#149 (closed)
  • gitlab-org/quality/performance#153 (closed)

Author's checklist

• Follow the Documentation Guidelines and Style Guide.
• If applicable, update the permissions table.
• Link docs to and from the higher-level index page, plus other related docs where helpful.
• Apply the documentation label.

Review checklist

All reviewers can help ensure accuracy, clarity, completeness, and adherence to the Documentation Guidelines and Style Guide.

1. Primary Reviewer

• Review by a code reviewer or other selected colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes.

2. Technical Writer

• Optional: Technical writer review. If not requested for this MR, must be scheduled post-merge. To request for this MR, assign the writer listed for the applicable DevOps stage.

3. Maintainer

1. Review by assigned maintainer, who can always request/require the above reviews. Maintainer's review can occur before or after a technical writer review.
2. Ensure a release milestone is set.
3. If there has not been a technical writer review, create an issue for one using the Doc Review template.