Route Gitaly storages through gitway behind a feature flag

What does this MR do?

Gitway is a new service that will sit in front of Gitaly. Long term, it will be the repository directory for GitLab and allows us to de-couple Rails from having to worry about where Git repositories live on Gitaly nodes.

The first iteration of Gitway is a pure gRPC passthrough to Gitaly. To roll this out safely however, we want to be able to ramp up traffic gradually. To do this, we will introduce an optional gitway_address to each repository storage, next to gitaly_address.

When the new route_gitaly_through_gitway ops flag is enabled, Gitlab::GitalyClient.address returns that storage's gitway_address instead of its gitaly_address.

Why

Nothing uses this yet. No environment sets gitway_address, and the flag is off by default.

We need it first for CI in gitway, a transparent gRPC proxy in front of Gitaly. Gitway's CI will run the Rails specs that call Gitaly twice: once direct, and once with a gitway_address configured, so the test env's traffic routes through a gitway instance. Any spec that fails only through gitway is a gitway regression, and that run is what gates gitway's merges. Without a second address that Rails knows how to pick, that CI job would have to rewrite every storage's gitaly_address.

Later, the same flag is the cutover mechanism for GitLab.com. Traffic can be ramped onto gitway by percentage and rolled back in seconds, with no config change or restart. Omnibus and the Helm chart need follow-ups to carry the key: omnibus-gitlab#10131 (closed) and gitlab-org/charts/gitlab#6695.

Relevant issues

Closes #632171 (closed)

Rollout issue: #632192

🤖 Generated with Claude Code