Spike to validate whether using logical replication will work on an omnibus package for a major version upgrade

From &5405 (comment 508274386) the longer vision would be the following:

We know we can't use it for our regular replicas, or geo, as it doesn't support truncate, as well as other limitations. But perhaps we can use it temporarily during a major version upgrade, while there aren't any gitlab migrations going on.

Thinking we wouldn't re-use any current db, replica or geo, but rather bring up new databases instances for absolutely everything, with just one point of logical replication:

1. Add logical replica slot to the primary db
2. Bring up a additional primary with the new version that is subscribing to the primary (have omnibus do this on the same node, with support for being on its own node)
3. Bring up the additional replias, using our regular replication from the new version primary
4. (Do the same thing on geo secondaries, so that we basically have two complete separate gitlab db setups, but the one new db version primary is using logical replication from the old db version primary)
5. Once replication has caught up

• swap all geo clients first to the new geo db clusters
• swap app primary clients to the new version

1. Remove the logical replication, shutdown the old databases
2. Remove the old data

But prior to committing work to omnibus in that direction we should manually configure logical replication in an existing test setups, and setup the replicas on a different pg version. And just see if everything can work this way as a way to do zero-downtime upgrades.