Is your feature request related to a problem? Please describe.

The schema changer has to not only support the elements produced in jobs from the previous version, it must also support the possible states that those elements might appear in. The fear is that changes in dependency rules might make it such that the current state as left by a previous version corresponds to an illegal state in the previous version. That may prevent progress from being made.

Describe the solution you'd like
We can run and serialize all of the possible states of any given set of statements and construct testdata with that. We could then, in that way, validate that all of the states can be planned. The question then must be, what is the catalog of schema changes to use to generate all of this state? One answer could be all of the local logictest files. They run quite a few interesting schema changes.

One could imagine taking all of the sql from all of the logic test files, and then, for each schema change, record each of the sequences of states, and then also consider doing the end-to-end style rollback tests to capture all of the sequences of states for all of the possible rollback paths for all of these schema changes.

For each of these serialized states, we could try to build a plan. If this works for each of them, I'd feel pretty good we didn't break anything.

Jira issue: CRDB-16577