Previous migrations might be reverted after setting a fallback version

[jonasraoni]

Describe the bug

• After setting the fallback version at a given point, the downgrade for previous and successfully migrations are being executed, but they shouldn't, see: https://github.com/pkp/ojs/pull/3895/files#r1207504069.

• As an improvement to the upgrade process, the "save point" should probably be set automatically after every successfully migration (e.g. Status: pre-3.4.0 failed at migration XYZ), it should make the life of technically skilled users easier.

• Re-think our downgrade strategy: Downgrades are mostly useful to allow users to revert to a previous version without losing newer data and to speed up things (e.g. run a couple of updates instead of restoring a huge dataset from a backup).
  Given that we have a win/lose condition (e.g. reverting a single database migration is pointless/wrong, unless we can do it on the code as well), we've got to either implement the down() method properly (store deleted data + ensure newer data will be handled properly) in all migrations or ignore it altogether (for now I personally support the latter).

Perhaps this should be a discussion 🤔

[asmecher]

I think this is resolved for 3.4.0 by having the preflight check migration be the first to run, and making it the only migration that sets a fallback (as it currently is). It's not a perfect model but for 3.4.0 I'm satisfied. If you'd like to open a discussion for some broader thinking about upgrades, it's probably a broader subject for consideration -- for example, there are a few exchanges about the usefulness/uselessness of down() migrations that we could include over there.