Geo: More robust Foreign Data Tables updates
### Summary (for the Release Post; describes potential future state) We currently experience a number of small issues when updating Foreign Data Tables during Geo updates. Many of these issues can be resolved manually be users already using e.g. `sudo gitlab-rake geo:db:refresh_foreign_tables`. This epics tracks the related bug fixes and UX improvements to resolve some of the underlying issues. ### Problem to solve When updating GEO, FDW schemas should be refreshed automatically. Currently, users often experience a `Geo database has an outdated FDW remote schema` error after an upgrade, which needs to be manually fixed. In addition, some of the messages presented in `sudo gitlab-rake gitlab:geo:check` are outdated and/or not required on the `primary`. ### Proposal * Fix UX isses in `gitlab::geo:check` * Automatically refresh FDW tables and fix associated bugs ### Higher intent Updates should just work and if we can perform required steps automatically as part of the update, we should. ### Intended users * [Sydney, Systems Administrator](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> * We may need to update screenshots and/or code blocks in the documentation showing output of `sudo gitlab-rake gitlab:geo:check` e.g. in the [troubleshooting guide](https://docs.gitlab.com/ee/administration/geo/replication/troubleshooting.html#fixing-foreign-data-wrapper-errors) ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> Increased automation often requires more testing in order to establish that operations succeeded. ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> * FDW schema is updated automatically ### What is the type of buyer? - Premium ### Links / references https://docs.gitlab.com/ee/administration/geo/replication/troubleshooting.html#fixing-foreign-data-wrapper-errors
epic