Check upgrade path requirements prior to upgrade
We put certain requirements on upgrade paths: https://docs.gitlab.com/ee/update/#upgrade-paths
For no-downtime upgrades, this is even more constrained since we require to go one minor migration at a time only. However, there are examples where self-managed installations don't adhere to this procedure and run into subsequent problems with database migrations (dependency problems, see gitlab#333257 (comment 600319933)).
The proposal here is to add a check to the beginning of the upgrade process to check whether or not the upgrade path is actually legit. If it's not, we can fail the upgrade early and explain what's going on. This is easier to rectify than an upgrade that went half-way through but failed on database migrations.