Draft procedures for recovering from when migration scripts won't apply after an upgrade

[msullivan]

We strive for backwards compatibility, but a huge swath of clear bugfixes can cause migrations scripts to fail to apply, since they can contain basically arbitrary expressions. (Additionally, we can cause these through introducing bugs, of course.)

The issue here is that we have at least two kinds of instances:

1. New instances, which are created by applying all migrations. If one of the migrations no longer applies, we can't create a new instance.
2. Existing instances, which will be upgraded with dump/restore and so don't need to actually run old migrations (assuming the problem isn't present in the latest schema---it can probably be fixed before upgrading), but which still has all the old migrations recorded in the database.

I can think of two potential approaches:

1. Destroy all existing migrations and replace them with a single migration to the current schema. Produce a query to run against existing instances that drops all existing migrations and inserts the new migration.
2. Perform "shortcut" migrations when creating new instances by directly migrating to the target schema, but populate schema::Migration as if they had all been applied.

This is related to the idea of migration squashing but I'm not sure if we have anything written down about that yet.

[elprans]

Yeah, I think our advice for "fixes that break old migrations" would be to do a manual migration squash. New regressions shouldn't require anything special other than waiting for a fix.

[msullivan]

We probably want to build a tool for it, then?