Container Registry: Implement methodology for post-deployment database migrations

Support for applying regular database migrations was implemented a while ago in #2566 (closed). As we complete the GitLab.com registry upgrade/migration, we're now in a position where the database has grown enough to make simple changes (like creating new indexes) take a long time to execute, so we need to introduce support for applying post-deployment migrations to roll these out safely.

On the container registry side, support for post-deployment migrations was implemented in gitlab-org/container-registry#220 (closed), on the same registry CLI that is currently used for applying regular migrations.

When applying up/down migrations with the CLI, by default, both regular and post-deployment migrations are considered, unless the -s/--skip-post-deployment option is passed as an argument, in which case post-deployment migrations are ignored. Therefore, we'll also need to modify the current scripts/db-migrate script used for applying regular migrations so that it ignores post-deployment ones.

Important: As done for the main DB, we need to connect to the PostgreSQL primary server directly instead of PgBouncer. This is because post-deployment migrations may take a long time to execute and as such, we need to be able to pin a single connection and disable statement timeouts for each migration. This is not possible if connecting through PgBouncer.

Cleanup

TO unblock the rollout of post-deployment migration on GitLab.com, we moved forward with using extraEnv on the k8s-workloads project to toggle the SKIP_POST_DEPLOYMENT_MIGRATIONS env var (sample). Once the automation is in place, we should make sure to remove that.