Tracking 'db:migrate:multi-version-upgrade' stability

The issue is to be used for tracking db:migrate:multi-version-upgrade stability for cases when job caused instability in master.

Tracking broken master incidents

• Friday 2024-04-19 19:11 UTC - `gitlab-org/gitla... (gitlab-org/quality/engineering-productivity/master-broken-incidents#5982 - closed) - %16.11
  • Details: caught an actual migration error and root cause MR was reverted gitlab-org/quality/engineering-productivity/master-broken-incidents#5982 (comment 1872369091), however caused master-broken since security_policy records were generated in 16.11 PG dump while in previous dump this table didn't exist - as such db:migrate:multi-version-upgrade didn't fail for Add sharding keys and update schema for securit... (!149730 - merged)
• Thursday 2024-05-09 18:32 UTC - `gitlab-org/git... (gitlab-org/quality/engineering-productivity/master-broken-incidents#6238 - closed)
  • Details: Caused by postgresql installation error in specific bookworm image - gitlab-org/quality/engineering-productivity/master-broken-incidents#6238 (comment 1900489347), happened once and next image didn't have this error.
• Tuesday 2024-09-10 17:22 UTC - `gitlab-org/gitl... (gitlab-org/release/tasks#13031 - closed)
  • Details: Backport from 16.11 was failing because it used latest_upgrade_stop.gz which is 17.3 on the time of writing.
  • Corrective action: gitlab-org/quality/quality-engineering/team-tasks#3028 (closed)

Proposed solutions

1. Disabling the job while investigation is ongoing to unblock master
2. If issues like this happen more often:
   • Adding db:migrate:multi-version-upgrade which would emulate upgrade from current master in author's MR (context gitlab-org/quality/engineering-productivity/master-broken-incidents#5982 (comment 1879130567))