As part of introducing thread avatars, we added edit_thread_avatar and descendant_edit_thread_avatar permissions to role-creator.js. Roles and permissions for all threads on prod keyserver were updated to include these permissions via a recent updateRolesAndPermissionsForAllThreads migration.
If during a state check a client's threadStore is "out of sync" with the keyserver, the client will need to pull down ALL threadInfos from the keyserver. This isn't the end of the world and doesn't break anything, but it can degrade the user experience and is something we want to avoid.
The first step in doing that was filtering out certain permissions on the keyserver when computing threadInfos to be compared against those on the client. To handle this we introduced filterThreadPermissions in thread-utils to filter out *edit_thread_avatar permissions.
However, now that we want to "switch on" avatars for new clients we WILL want the keyserver to be including *edit_thread_avatar permissions in the threadInfos it computes. Because the client won't have the *edit_thread_avatar permissions persisted, there would be an inconsistency the first time the client connects to keyserver after updating the app to a codeVersion that supports avatars.
To handle this initial inconsistency, we want to introduce a migration that modified the client's persisted roles/permissions in the threadStore AFTER we update the client but BEFORE we establish connection with the keyserver.
We've done this twice in the past with edit-thread-permission-migration and manage-pins-permission-migration. I used those two migrations as a guide and tried to follow them as closely as possible.
