Improve safety of migrations

[Gudahtt]

Our state migrations can sometimes leave users in unrecoverable states, or lead to loss of data. This can happen not just when we introduce bugs in the migration script, but also when the user's state has been corrupted somehow in a way that we didn't anticipate.

We should strive to ensure our migrations never result in either of these two states. In a recent standup we discussed various prevention ideas:

• More comprehensive unit tests, to ensure that invalid state remains no worse off than it started when the migration is run
• Save a copy of the previous state whenever a migration fails, for us to use to recover data in a future migration
• Use TypeScript to ensure we write more robust migrations (specifically using the unknown type, so we are forced to test every assumption)
• Write e2e tests for migrations
• Re-initialize to a blank state in all relevant controllers whenever an error is encountered (maybe in combination with the "save a copy of previous state" idea).

This issue represents the continued exploration of how we can improve the safety of our migrations. We may want to consider additional ideas, and build prototypes to investigate the effectiveness/feasibility of these ideas. The output should be a concrete plan for how to improve our migrations (or the solution itself, if that's easier).

[Gudahtt]

Currently the fixture we use in e2e tests is just... whatever state the wallet was in when the test was written. We don't make a habit of updating fixtures, so problems resulting from specific wallet states may go undetected by CI.

We could adopt a practice of regularly updating fixtures to match the latest production wallet state. This would ensure our CI tests match the experience of current production users more closely. Or we could keep a collection of fixtures to represent new, currrent, and older users. e.g. each fixture would have a version for:

• The current wallet state
• The current production wallet state
• An ancient wallet state

Currently updating fixtures is a manual process. It's not trivial to automate it because state changes might happen as a result of a migration, or it might happen because of a change in a controller. The only reliable way to get an updated fixture is to run the real extension and export the state after initialization. We could automate fixture updates by doing exactly that though, and using our e2e tooling to start the extension up and export state to disk.