todo order is wrong

[aryairani]

Neither working through from the top down nor the bottom up in the todo list after a type refactor necessarily gives work in dependency order.

I'm omitting the specific example because it isn't public code, and we imagine it could be minimized further anyway.

The symptom was that working todo 1/112 required us to first complete todo 40/112. Working from the bottom up also didn't work, thus we think the order heuristic must be wrong or broken.

[pchiusano]

For one, you want to update dependent types. Then any functions that do direct pattern matching or call the constructors directly. Then everything else in dependency order.

The todo output should also be an antichain. If entry A depends on entry B, then only B should be listed. Reasoning: there's no sense updating A until its dependencies have all been updated.

[ceedubs]

Related to #2248

[aryairani]

superseded by #5088, though we may still revisit if we implement something like this again in a future update process