Add MFE configuration section and kill switch
What does this MR do and why?
Configuration foundation for registry-direct micro-frontend (MFE) delivery: an optional gitlab.yml mfe section reduced to exactly two settings — enabled (static kill switch) and registry_url (static, CORS-enabled registry host, default https://mfe.gitlab.com) — plus Gitlab::Mfe.enabled? gated by the new mfe_enabled feature flag (:instance actor).
Nothing reads this configuration yet — the vendor pin file, bake task, version overrides, admin UI and runtime loader follow in the next parts of the stack.
This series supersedes the previous pull-through-proxy stack (parts 1–5 starting at !245043 (closed)): the redesign removes all runtime server-side download machinery. Baked versions ship as static release assets; newer versions load in the browser directly from the registry with SRI, falling back to baked on any failure.
How to verify
bin/rspec spec/lib/gitlab/mfe_spec.rbWith no mfe: section in gitlab.yml, Gitlab::Mfe.enabled? is false and registry_url returns the default; with mfe: { enabled: true } and the flag enabled it is true.
Stack
Registry-direct MFE series; each part is independently reviewable and leaves master inert (double-flag-gated, nothing user-reachable until a surface flag flips). Merging bottom-up.
| # | Scope | MR |
|---|---|---|
| 1 | Config section + instance kill switch | this MR |
| 2 | Vendor pin file + registry manifest schema + verified bake task | !246736 (closed) |
| 3 | Version overrides table + resolver | !246753 (closed) |
| 4 | Admin API + routes + sidebar | !246758 (closed) |
| 5 | Admin UI (Vue) | !246764 (closed) |
| 6a | Runtime loader: gon contract, SRI, baked fallback, CSP connect-src | (planned) |
| 6b | Duo Chat consumer behind mfe_duo_chat |
!246778 (closed) |
| 7 | Developer mode (local dev server + HMR) | !246833 (closed) |
Related
- Phase 1 issue: #605798
- Epic: gitlab-org#22777
Related to #605798.