Query access handler

@pcambra @paul121 and I have been discussing this at length, and we've come to the conclusion that this should *not* be implemented in the Log module. Rather, the farmOS distribution can make modifications to the log entity definition if it so desires.

See #3415653: [META] Allow more granular access on default farmOS Views →

Closing this as "won't fix".

Reopening this. @pcambra @paul121 and I discussed more today and discovered that accessCheck(TRUE) is having no effect on log queries. So we decided to move forward with this after all as a bug fix.

We *may* need to consider this a breaking change, though, which would necessitate a major version release.

As change notice said each query should use accessCheck(False) as log recods has no view permissions vary

Thanks @andypost!

The reason we should consider this a breaking change is that right now accessCheck(TRUE) and accessCheck(FALSE) make no difference to the list of logs returned based on user permissions. This is because the Log entity uses the Entity API module's permissions_provider handler, but not its query_access handler, which is responsible for modifying the Log entity queries based on user permissions.

We are going to start using the Entity API query_access handler, which means that any lists of logs that are currently being built with accessCheck(TRUE) (including Views) may change for users. They will arguably change for the better, because they will actually be respecting user permissions better, so this is a bug fix. But nevertheless it is a bug fix that changes current behavior, so I think it's worth a major version bump to make it clear to users of the Log module that they might want to check their implementations.

Looks like we'll need to fix some failing tests...

Hmm drupal.org tests are failing on 2.x in general... not specific to this MR. They are all passing locally for me (except for this know psql issue: 🐛 LogActionsTest::testRescheduleMultipleLogsRelative() fails on PostgreSQL Needs work ).

So I think this is good. Setting back to Needs Review.

But nevertheless it is a bug fix that changes current behavior, so I think it's worth a major version bump to make it clear to users of the Log module that they might want to check their implementations.

I have opened a 3.x branch for this.