define what it means to call actionAccess() without a flaggable, and fix implementations to do it

Changing this to a code task after more investigation.

> Entity Field Access has the same, one use case there is that views field plugins can check that and if that returns false, they can hide the whole column instead of displaying a lot of empty table cells.

When you pass a flaggable, more possibilities for granting access are opened up.

Eg, if you call with a flaggable, you might be allowed access because you own the flaggable node and you have the 'flag own nodes' permission. If you don't pass the flaggable, that permission won't get checked.

I suppose we could add a check on 'flag own nodes' permission without a flaggable, and then we can reliably say the user can't have access. It would need to be made clear in the docs that it wouldn't be a reliable return value when access is granted though. In other words, without a flaggable, you could either get 'definitely no access' or 'maybe some access'.

Ok that makes sense.

In which case, this issue needs to:

- add detail to the documentation to define what the behaviour should be when $flaggable is absent
- fix the implementations to do that

> An access without actual items/entity means "there are probably entities/fields out there that you can edit",

So does that mean that without an actual item, we should return either AccessDenied or AccessNeutral only?

> Entity Field Access has the same, one use case there is that views field plugins can check that and if that returns false, they can hide the whole column instead of displaying a lot of empty table cells.

I think there's a problem with this because our Flag::actionAccess() method includes the $action parameter. If you're checking for the column in a view result, you can't know the $action in the absence of a flaggable entity.

Should we rethink the passing of the $action param when there's no flaggable?

In the meantime, here's a patch for the docs and logic change when $flaggable is omitted.

The more I think about this, the more I think that passing the $action without the $flaggable makes no sense.

It certainly doesn't work in the use case of a column of flag links in a View formatter for a table, and once #2867134: flag checkboxes on entity edit form don't check access based on extra permissions is fixed that's the only use case we have for this.

It also means that getUsersFlags() has to do this:

      if ($flag->actionAccess('flag', $account)->isAllowed() ||
          $flag->actionAccess('unflag', $account)->isAllowed()) {

which means all the hook & plugin code is run twice!

Proposed new issue summary:

The actionAccess() API has two ways of being called:

- with a flaggable entity, to get a definite answer about access to flag that entity
- without a flaggable, to get a non-definite answer that's 'you might be able to do things with this flag, but ask me with a specific flagging to be sure'

Currently, the implementations of this don't actually properly implement the non-flaggable version. Those should be fixed.

But before we fix them, I think we should examine the use cases for the non-flaggable version, as I don't think passing the $action in this case makes sense.

There is only one use case that I am aware of:

- a View showing a table where one field is a flag link can hide the whole column if the user has no access to the flag.

Passing in an $action parameter makes no sense here, because without a flaggable entity, you don't know whether you might want to flag or unflag.

Therefore the proposal is:

- change the signature of actionAccess() so the $action is also optional
- document what the non-flaggable case means and what it actually tells you
- fix implementations to behave properly

Postponed on #2870375: remove getUsersFlags(), which itself is postponed on #2867134: flag checkboxes on entity edit form don't check access based on extra permissions....

Thanks!