This addresses ENG-9030.

The memberUserSurfacedPermissions calculation currently in the codebase basically controls the default set of user-surfaced permissions granted to a member.

The problem is that right now, this default set is different depending on the community root's ThreadType. I think the intention of that logic is to restrict permissions in the community root, but user-surfaced permissions are meant to be global for the whole community, so this doesn't make sense.

This issue wasn't noticed prior to D13017 because the user-surfaced permissions were only affecting the root. Now that they're affecting the whole community, we need to revisit this logic.

This diff introduces a new approach:

1. The code for determining memberUserSurfacedPermissions is removed, in favor of assigning the same set of default user-surfaced permissions to all members, regardless of the community root's ThreadType.
2. We also remove a similar distinction in getRolePermissionBlobs for announcement subchannels, since they can be handled by the same mechanism that we need to replace point 1 above.
3. Both 1 and 2 are replaced with logic in makePermissionsBlob, where we subtract a set of permissions for announcement threads where the user doesn't have VOICED_IN_ANNOUNCEMENT_CHANNELS.

Depends on D13067

I did the following testing in my local environment after running a migration to reset permissions:

1. I tested an announcement community root and confirmed that:
   • Admin had permissions to send messages in the root
   • Non-admin did not have permissions to send messages in the root
   • Non-admin did have permissions to send messages in other channels
2. I tested a non-announcement community root and confirmed that:
   • Admin had permissions to send messages in the root
   • Non-admin had permissions to send messages in the root
   • Non-admin had permissions to send messages in other channels
3. I tested GENESIS and confirmed that:
   • Admin had permissions to send messages and react in the root
   • Non-admin did not have permissions to send messages or react in the root
   • Non-admin had permissions to send messages and react in other channels