Implement the query access handling for grouped entities

Might be blocked by both of these:

• #3086409: Provide a default query_access handler for core (maybe all?) entity types
• #3134363: Support a catch-all QueryAccessEvent for modules that may want to alter all entity queries

And could be improved by #3134160: Support all operations in query access alters

Attached is a proof of concept that requires the two Entity API patches listed above. It hasn't got tests yet, but it shows how we would handle any entity query through this system. If it works, we can do away with node grants altogether.

@Berdir I've thought of that :)

• Existing entities will not get any change unless they implement the permission_provider handler in their GroupContentEnabler plugin.
• GroupNode will receive this change, but we'll be deleting all of the grants code at the same time so the net result should be (almost) no changes, aside from a hopefully large performance boost
• Group memberships don't enforce entity access so nothing changes there either

And the release notes will indeed very prominently explain the new option of a permission provider and the fact that adding one to your plugin, even if only the default one, will automagically make all your entity lists secure.

More on point: having to change your queries is indeed a nuisance we have to get past. It's either have no query access checking and be considered insecure, or have query access checking and require people to update their custom queries so they have proper access checks (or none at all).

Commerce ran into the same issue, which is why Bojan did not want to break core all of a sudden by polyfilling the access handlers for all of core's entity types. See #3086409-2: Provide a default query_access handler for core (maybe all?) entity types

+++ b/src/EventSubscriber/QueryAccessSubscriber.php
@@ -0,0 +1,239 @@
+        // For backwards compatibility reasons, if the group content enabler
+        // plugin used by the group content type does not specify a permission
+        // provider, we do not alter the query for that group content type. In
+        // 8.2.x all group content types will get a permission handler by
+        // default, so this check can be safely removed then.
+        if (!$this->pluginManager->hasHandler($plugin_id, 'permission_provider')) {
+          continue;
+        }

These lines will ensure no sites break all of a sudden. In the other patch (for the relation aka GroupContent entities), we took the same approach. So only GroupContent queries might break for members and group nodes. And by "break" we mean they will no longer return all members, but only the ones you are allowed to see. So it really boils down to a security fix again.

This is the latest version, it has cache tags and deals with the owner properly. Was previously looking for the owner of the group content, whereas it should be looking at the owner of the grouped entities. The beauty of this all is that bundles are taken care of automatically because plugins are bundle-aware :)

Will start writing tests now. I have similar tests in Subgroup, so I'll use those as a starting point.

Fails are expected, they relate to the new Entity API code (which we can't require yet until a new Entity API release is out).

Yup, thanks for that. Found a few bugs while writing tests, will update in the next patch.

Now with working tests and various fixes, as soon as Entity API commits and releases #3086409: Provide a default query_access handler for core (maybe all?) entity types

Yeah I added new test-only plugins and that caused the issue. "Documented" this in the test module's info.yml file even though that doesn't do anything and added it to the tests that were failing on it.

Reroll, going to commit with the dev dependency for now so I can test/clean up the rest of the release. Will change to entity:1.1 before release.