We can simplify this check because of two properties:

1. I grep'd around and confirmed that despite supporting RawThreadInfo | ThreadInfo, threadIsGroupChat is only ever called with a ThreadInfo parameter. This is confirmed by Flow.
2. In D8072, @rohan updated getRelativeMemberInfos to filter out anybody with a "falsey" role from a ThreadInfo. RawThreadInfo will still have these members, but since threadInfoFromRawThreadInfo calls getRelativeMemberInfos to determine its members property, that means that a ThreadInfo will NEVER have a member with a falsey role.

Given these two observations, I've made three changes:

1. Restricted the function parameter to only take a ThreadInfo.
2. Remove the call to threadMembersWithoutAddedAshoat. This function never removes members unless they have a falsey role, so it is a no-op in this case.
3. Remove the filter. Similar to above, this filter never removed members unless they had a falsey role.

By removing the member.permissions check, we now have only one such check on the client left. That check can be addressed in ENG-4155, at which point we could remove member.permissions entirely, which would greatly reduce the size of the ThreadStore.

Careful reading and Flow