updateClientDBThreadStoreThreadInfos handles converting CommCoreModule representation of ClientDBThreadInfos to "JS side" representation of RawThreadInfos, applying some sort of migrationFunc, and then converting RawThreadInfos back to ClientDBThreadInfos and updating the SQLite DB. More detailed description of each step can be seen as code comments in the diff.

It's a common pattern (at this point) to make updates to the SQLiteDB BEFORE we REHYDRATE Redux. To avoid duplicating business logic and to reuse all the rich functionality we already have on the JS side we convert from CommCoreModule representation to JS representation, make the changes, then convert back. This utility function handles all of that and accepts a single migrationFunc to update the contents of each ThreadInfo.

The functionality in this diff is mostly from migration 36 where it was shown to be correct. In addition it was used in D7551 where it also was shown to be correct (the issues there were related to the permissions business logic, not the behavior of the code in this diff... so although this diff is "dangling," its functionality has been used + tested.

This functionality will shortly be consumed by the client version of updateRolesAndPermissionsForAllThreads. Separating this from that because they're both complex "chunks" of code and IMO should be reviewed separately.

This logic was lifted from migration 36 where it was shown to be correct.

I also tested this logic thoroughly as part of D7551. While there were issues with my persistMigrationForThreadAvatarPermission logic, the code within this diff worked perfectly as expected.