Change Details

[ENG-10595](https://linear.app/comm/issue/ENG-10595/implement-js-sqlite-migrations). Depends on D14774

[ENG-10595](https://linear.app/comm/issue/ENG-10595/implement-js-sqlite-migrations). There is a lot of context in [Backup migrations scoping](https://www.notion.so/commapp/Backup-migrations-scoping-1d6d823c518b805c9313e1f2f1584b6a). This diff creates a system on how to implement and run JS migrations compatible with backup. I think this is the best solution because it has no impact on the existing migration process, and gives the same flexibility in migrations as before. The only thing to consider now is that whenever writing a migration, the DB ops code has to be factored out to `sharedMigrations` and just call it in the redux-persist migration. That way, we're able to run it again on the database downloaded from the backup. As mentioned in the docs, there are 4 types of migrations: 1. T1 - Schema migrations - executed after downloading the database, it was implemented in this stack in prior diffs, the final diff is D14752 2. T2 - SQLite data migrations using redux-persist - this is primarily solved by this diff, I created D14782 that shows how to do it 3. T3 - Redux-only migrations - those shouldn't be executed when restoring backup (already having the newest, probably default state), but we still need to run it on app start on existing clients, for this migration type approach remains unchanged, see example in D14783 4. T4 - SQLite and Redux migrations - this is the complex because it could affect both DB and state, and when running backup migration, we shouldn't modify existing state. But thanks to this approach, we still can achieve it by separating DB ops code (`sharedMigrations`) with state migrations (put in the same place as before). In D14782, there is an example of migration that is executed on the backup, but existing clients can modify the state, too. Because of that, we can cancel [ENG-10597](https://linear.app/comm/issue/ENG-10597/remove-using-state-from-unshimclientdb) Depends on D14774

[ENG-10595](https://linear.app/comm/issue/ENG-10595/implement-js-sqlite-migrations). There is a lot of context in [Backup migrations scoping](https://www.notion.so/commapp/Backup-migrations-scoping-1d6d823c518b805c9313e1f2f1584b6a). This diff creates a system on how to implement and run JS migrations compatible with backup. I think this is the best solution because it has no impact on the existing migration process, and gives the same flexibility in migrations as before. The only thing to consider now is that whenever writing a migration, the DB ops code has to be factored out to `sharedMigrations` and just call it in the redux-persist migration. That way, we're able to run it again on the database downloaded from the backup. As mentioned in the docs, there are 4 types of migrations: 1. T1 - Schema migrations - executed after downloading the database, it was implemented in this stack in prior diffs, the final diff is D14752 2. T2 - SQLite data migrations using redux-persist - this is primarily solved by this diff, I created D14782 that shows how to do it 3. T3 - Redux-only migrations - those shouldn't be executed when restoring backup (already having the newest, probably default state), but we still need to run it on app start on existing clients, for this migration type approach remains unchanged, see example in D14783 4. T4 - SQLite and Redux migrations - this is the complex because it could affect both DB and state, and when running backup migration, we shouldn't modify existing state. But thanks to this approach, we still can achieve it by separating DB ops code (`sharedMigrations`) with state migrations (put in the same place as before). In D14782, there is an example of migration that is executed on the backup, but existing clients can modify the state, too. Because of that, we can cancel [ENG-10597](https://linear.app/comm/issue/ENG-10597/remove-using-state-from-unshimclientdb) Depends on D14774