Retarget links away from Cells 1.0/1.5/2.0 iteration pages

## Context

[Initially](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/139519) Cells 1.0 was created for new customers only.

Finding new customers willing to onboard on untested infrastructure turned out to be a challenge, especially with [missing features](../iterations/cells-1.0.md).

Finding new customers willing to onboard on untested infrastructure turned out to be a challenge, especially with missing features.

Not having a customer in mind makes it impossible for us to define scope of which features to deliver.

## Decision

1. `secret_key_base` is used for: encrypted cookies, signed cookies, and Active Storage files, based on https://guides.rubyonrails.org/security.html#session-storage.

   We don't use Active Storage, as far as I know, so it's only cookies that are affected. Given that for Cells 1.0, users will be tied to a single cell, and since

   [the session cookie will include the cell ID in its name](../iterations/cells-1.0.md#proposal), it's fine to have a unique `secret_key_base` per Cell.

   [the session cookie will include the cell ID in its name](../http_routing_service.md#cell-infrastructure-routing), it's fine to have a unique `secret_key_base` per Cell.

   Investigation issue: [`secret_key_base`](https://gitlab.com/gitlab-org/gitlab/-/issues/451146).

1. `db_key_base` is used for encryption at rest in the database, and will need to be consistent across all Cells, so that

   data can be moved easily between Cells.

@enduml

```

For [Cells 1.0](../iterations/cells-1.0.md) our aim is to have up to 10 cells inside `ring 2`.

For Protocells our aim is to have up to 10 cells inside `ring 2`.

The number of Cells in a ring is arbitrary, their size is still to be determined.

It will take into consideration our necessity to [adequately test auto-deploy packages before a public release](deployments.md#package-rollout-policy),

the speed of a full production rollout for security fixes,

regardless of their size or number.

This document will discuss the requirements for such a system. It targets

the [Cells 1.0](../iterations/cells-1.0.md) iteration.

the old Cells 1.0 iteration.

## Motivation

#### Things to validate

Dividing the scope based on the Cells iterations https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/cells/#cells-iterations

Dividing the scope based on the old Cells 1.0/1.5/2.0 iterations.

##### Cells 1.0 (Initial Scope)

(Focus: Foundational validation and integration tasks for the Cells 1.0 release)

The target of Cells [Cells 1.0] (../iterations/cells-1.0.md) is to deliver a solution for internal customers using the SaaS GitLab.com offering, and foundational work for Cells.

The target of Cells 1.0 was to deliver a solution for internal customers using the SaaS GitLab.com offering, and foundational work for Cells.

- Evaluate and integrate CloudSQL's database observability and automated telemetry collection tools into GitLab's observability suite.

  - Is [Query Insights](https://cloud.google.com/sql/docs/postgres/using-query-insights) a sufficient replacement for the current observability tooling?

(Focus: Features and validations for later iterations)

The target of [Cells 1.5](../iterations/cells-1.5.md) is to deliver a migration solution for existing and new enterprise customers using the SaaS GitLab.com offering, built on top of the Cells 1.0 architecture.

The target of Cells 1.5 was to deliver a migration solution for existing and new enterprise customers using the SaaS GitLab.com offering, built on top of the Cells 1.0 architecture.

- Validate a connection pooling solution for both Write and Read-Only workloads:

  - PgBouncer on VMs