[native] Introduce recursivelyUpdateRoles(ThreadTraversalNode)
Summary:
We introduce recursivelyUpdateRoles(ThreadTraversalNode) which updates threadInfo.roles.permissions corresponding to the node.threadID AND all child threads (node.children) recursively.
NOTE: We're not mutating or updating the ThreadTraversalNodes, we're simply using them for traversal. We ARE, however, mutating the threadInfos "directly" by mutating the ThreadStoreThreadInfos passed into updateRolesAndPermissions by indexing into it w/ node.threadID from the ThreadTraversalNodes.
Depends on D7600
Test Plan:
- Ran migration on existing threadStore and there was no diff
- Added "atul" permission to voiced and observed that it was included thanks to migration: https://blob.sh/6b2616.png
- Removed misc permissions and observed that they were excluded after migration
Later in the stack I add test cases to check that recursivelyUpdateRoles makes no changes to a "correct" threadStore retrieved from the keyserver on login AND that recursivelyUpdateRoles can construct correct threadInfo.roles.permission with all existing role permissions removed (AKA can do it from scratch solely based off of getRolePermissionBlobs.
WARNING: Right now we're updating roles.permissions for roles that exist for a given threadType. That means that we can handle updating of Members or Admins if they already exist for a threadType, but we CAN'T add or remove roles to threadInfo.roles... that requires the keyserver in order to generate the roleIDs. So we can't quite build up roles/permissions entirely from scratch as we can on the keyserver... though I'm not sure how likely it is that we add/remove a role for an existing thread type vs creating a new thread type. Either way, in that scenario the developer introducing the change would be responsible for ensuring there are no inconsistencies and that may involve additional work.
Reviewers: ashoat, ginsu
Reviewed By: ashoat
Subscribers: tomek
Differential Revision: https://phab.comm.dev/D7601