[11.x] Add the ability to limit scopes by client

[axlon]

Redo of #747 - which, it seems, was closed because of ongoing discussions at the time, not because of any technical reasons

What does this PR do?

This PR adds the ability to restrict what scopes a client may request, this can be useful when there is a need to restrict access to certain scopes for some or all of an application's clients.
If there is no scopes column or if it not set the client is allowed to request any scopes that are available, this makes the change backwards compatible. If the scopes column is set, Passport will check if the requested scope is permitted and if it isn't it will be skipped.
Similarly to the way the grant_types column works, this PR doesn't add a migration for the scopes column and devs should add the column themselves if they find they need this feature. Additionally if a developer wants to handle restricting scopes in a totally different way they could do this easily by extending the Client model and overriding the hasScope method.

[driesvints]

Thanks @axlon. Can you also send a PR to the Passport docs?

[axlon]

@driesvints will do!

[Smoggert]

This is a breaking change btw.

Changing the constructor of an app bound repository.
Good thing it just broke on dev for us.

[driesvints]

@axlon it seems @Smoggert is correct. Anyone directly instantiating the ScopeRepository will see their app break. Can you send in a follow up PR to make the dependency nullable and change the logic? Otherwise we'll have to revert this one.

[axlon]

@Smoggert Sorry, I did not consider people would be using this class directly, this is very clearly a breaking change.

@driesvints yeah I was looking into a fix, that seems like a decent one but it still changes the constructor. How do you feel about doing something like this:

    public function finalizeScopes(
        array $scopes, $grantType,
        ClientEntityInterface $clientEntity, $userIdentifier = null)
    {
        $clients = app(ClientRepository::class);
        ....
    }

[driesvints]

@axlon if you make the clients dependency nullable then you can check that for the logic you added. Fallback to the old one if there isn't one set

[axlon]

@driesvints makes sense 👍