Rework group roles into a scoped system and adjust permission calculation

Updating the IS to provide way more details.

A key difference is how we will join said table to figure out which groups you have outsider permissions to:

MySQL [drupal]> SELECT g.id, g.type, gc.entity_id FROM groups g LEFT JOIN group_content_field_data gc ON g.id = gc.gid AND gc.type LIKE '%-group_membership' AND entity_id = 3;
+----+---------+-----------+
| id | type    | entity_id |
+----+---------+-----------+
|  2 | bar     |         3 |
|  3 | default |      NULL |
|  4 | foo     |      NULL |
+----+---------+-----------+
3 rows in set (0.00 sec)

MySQL [drupal]> SELECT g.id, g.type, gc.entity_id FROM groups g LEFT JOIN group_content_field_data gc ON g.id = gc.gid AND gc.type LIKE '%-group_membership' WHERE entity_id = 3;
+----+------+-----------+
| id | type | entity_id |
+----+------+-----------+
|  2 | bar  |         3 |
+----+------+-----------+

As you can see, the former will join the groups table with all of the group memberships for user 3 or NULL if there is none. The latter will join ALL of the group memberships for all groups and then filter those owned by user 3. We definitely need the former.

This is because we want to be able to run a condition WHERE entity_id IS NULL so that we can find all of the groups the user isn't part of but are of the selected group types we know the user would have outsider access for. This should be a hell of a lot faster than an IN(thousands of memberships) condition on sites where people can join a large amount of groups.

#3254311: Denormalize group_type and plugin_id for GroupContent entity and add indexes has landed and should make this issue easier to get done.

As far as the roles are concerned, I've given it some more thought and I think we can do without special-casing anonymous. If we mark the role as non-member, we can still cache it using group.roles, BUT people can add extra calculators to it to perhaps give anonymous access to some specific groups (e.g.: free membership for one month to select groups).

The idea would be to have all roles flag as non-member or member and then add them to the calculated permissions as a "group type scoped" set of permissions. With the reworked table structure, we can then easily join on all of the group types that would give access and where the user is not a member of.

1. Anonymous role would be: scope non-member, audience anonymous
2. Outsider (Authenticated) role would be: scope non-member, audience outsider
3. Any other global role that requires no membership: scope non-member, audience outsider
4. Member role would be: scope group, audience member
5. Any other global role that requires membership: scope group, audience member

You can clearly see why we can roll 3 into 2 and 5 into 4 here: They have become the same thing :) We can still optimize the anonymous permissions also because we know they can never be a member, so all the query has to check for is group types, we don't even need to join the group_content_field_data table for those.

Also, you should now be allowed to edit and delete the Member and Outsider role as you can always restore them. Probably the Anonymous role too, but I need to put some more thought into that.

Following up on #4, we can simplify the access query to the one shown there and then adding on the following:

WHERE
   # Outsider access for entire group type.
  (type IN types_with_global_outsider_access AND entity_id IS NULL)
OR
   # Insider access for entire group type
  (type IN types_with_global_insider_access AND entity_id IS NOT NULL)
OR
   # Specific (non-global) member roles access.
  id IN ids_with_specific_member_access

Where we would make sure that the list of IDs is not populated with any ID that is of a type allowed by types_with_global_insider_access. That should keep the list of IDs smaller.

@jozzy_a judging by that module's description: Yup.

This system would automatically work for Subgroup as it merely introduces one more calculator. It already does so in the current version and will continue to do so in the next.

Drupal Role Y for Non-Members" and "Drupal Role Y for Members

That is correct. It is necessary for the use case where you want the old behavior or you want a global user to have different permissions based on whether they're in or out of the group.

would it be feasible to grant them access like Group Role X if they are members of OtherGroup Z

That is how Subgroup works, yeah.

This should break a bunch of tests, especially those that still use now removed constants, those that rely on default group roles being created, etc. These are good things as we needed to refactor those tests anyway. But let's see just how much we can break :D

Error: Call to a member function grantPermission() on null is because the roles no longer get automatically created, which is a good thing.

Fixed a bunch of unit tests already. Going to use a merge request branch from this point forward.

So all that's left is to fix the field_storage going missing in Views tests, fix the EntityOperationsTest and move the query tests to new places while refactoring them. And then handle the todos, perhaps in follow-ups.

This patch is getting way too huge, I would normally reject that right away, but screw it. No-one's reviewing this beast and I'll make sure to write all the change records before this is marked fixed. Anyways: Introduced a base Views test class and fixed some issues.

I removed the chain permission calculator test and moved the code to specific tests per calculator. We might want to unit test the chain calculator, though, with dummy calculators.

Okay so I significantly updated the code for group and group content query alters and their tests. We should definitely have a follow-up issue where we look at EntityQueryAlter and also upgrade it accordingly.

If the tests go green (which they should), then the only thing that remains is to create smaller follow-up issues for all the todos added in this patch and to write a bunch of change records for the changes introduced here.

Updated title and IS to better reflect what happened here.

Things that need a change record:

Group role:

• audience, internal and permissions_ui properties removed
• scope and global_role properties added
• advanced outsider removed
• special roles removed, now an option on the group type form, methods on GT gone
• synchronizer service removed

Calculators:

• Heavily simplified into two methods
• Put into their own module (create follow-up issue)
• Have a base class now

Query access:

• No more Entity API usage
• All custom query handlers

Various:

• Test rework, no more default config, need to be specific now

Issues that need to be created:

• Rework EntityQueryAlter and test according to latest improvements to GroupQueryAlter
• Fix todos in GroupRoleStorage
• Fix todo in RelationTypeManager
• Put calculators in their own module
• Disallow plugins that define entity_access and concern group entities
• Disallow plugins that concern group_content entities

CRs and follow-ups created, let's get this in.