Consider a generic schema migration framework for CryptoStore

[richvdh]

Currently, each CryptoStore implementation (IndexedDb and Sqlite) has its own migration system for updating the schema on each update. It has been suggested that we could instead implement a migration system at the CryptoStoreWrapper level which can update the data objects without needing to implement the changes twice.

[richvdh]

My concerns about this are:

• We would end up adding methods to the CryptoStore trait that would only be used by these migrations.
• Often, migrations can't be done at the generic level - they require manipulation of indexes, or other changes to the way that data is stored in the specific store implementation; or it's just inefficient to do it at the generic level. And, since migrations need to happen in the right order, this would mean a complex interaction between "generic" migrations and "per-store" migrations.

[BillCarsonFr]

For context, I am giving a real life example of migration.
For this issue we need to add a new was_previously_verified flag boolean in the OtherUserIdentityData struct.

We have a techincal way to set the initial value of this flag by using serde(default). But this is not suitable for our need because in order to setup this flag I need to access my own identity as well as the identity we need the flag for. So we cannot compute the correct value.

An alternative could be to change the flag form a bool to an Option and set it to None. That way we could lazily migrate the data when we access them. But it feels bad to set something optional just because of migration?