Require new gitlab_main_cell_settings schema to have certain requirements

• The following discussion from gitlab-com/content-sites/handbook!11109 (merged) should be addressed:

• we remove enumerative tables, replace them with code
• we expect SRE to build external tooling for synchronising settings
• I'm in favor of making all clusterwide settings tables read-only, and making the UX read-only
• to above we could consider leaving those read-write on legacy cell (cell 1), but then tooling would have to pull the settings from there
• we simply do not build integrated synchronization
• we require that all clusterwide settings tables have API, ideally REST API, documented with OpenAPI
• this means that for all cases that have broadcast messages, or others, it is external tooling to deal with synchronization of it (either using Cell 1 as source, or doing that fully via API)

• I'm in favor of making all clusterwide settings tables read-only, and making the UX read-only

• to above we could consider leaving those read-write on legacy cell (cell 1), but then tooling would have to pull the settings from there

To be precise, it will be read-only except when updated via the API. I can open a follow-up issue on this.

• > Can we introduce gitlab_main_clusterwide_settings to provide a clear-indication of those tables?

Yes, I will open a follow-up about this.

• > we require that all clusterwide settings tables have API, ideally REST API, documented with OpenAPI

Yes, I will open a follow-up about this.

• Also update links to gitlab-com/gl-infra/tenant-scale/cells-infrastructure/team#246 (closed)

Action items

• Set up new gitlab_main_clusterwide_settings gitlab schema
• Investigate, and quantify extent of API coverage