With Geo, skip automatic upgrades of PostgreSQL

Problem

PostgreSQL servers will be upgraded to version 11 automatically with GitLab 12.10.

For installations using Geo:

1. Upgrading the Geo primary's PostgreSQL server breaks replication to all secondaries. It requires all secondaries to upgrade PostgreSQL server, it requires manual action on each secondary to start replication again, and replication can take hours or days to complete. https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance
2. Upgrading a Geo secondary's read-replica's PostgreSQL server breaks replication to it similar to point 1
3. Upgrading a Geo secondary's standalone tracking DB's PostgreSQL server doesn't work at the moment #5242 (closed)
4. Downgrading a Geo secondary's standalone tracking DB's PostgreSQL server doesn't work at the moment #5243 (closed)

Customers can manually disable automatic PG upgrades before upgrading GitLab, but it can be guaranteed that some proportion of Geo customers will accidentally trigger hours or days of downtime and bad experiences.

Proposal

• If Geo is detected, skip automatic PG upgrades.
• Adjust docs to take this into account
  • https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance
  • https://docs.gitlab.com/ee/administration/geo/replication/version_specific_updates.html Tell Geo customers to upgrade to PG 11 manually after upgrading to 12.10, because it will be required in 13.0 for reasons X, Y, Z

Questions

• My understanding is we will block GitLab upgrading to 13.0+ if using PG 10 or earlier?
• If in an HA deployment, will all nodes know what PG versions are being used in other nodes, in order to block the GitLab package upgrade?

@ljlane @ibaum @twk3 @fzimmer @nhxnguyen @toon