Fix including interval in response of device authorization request

[hafezdivandari]

This PR does:

• Fix a typo on DeviceCodeRepositoryInterface::getDeviceCodeEntityByDeviceCode() argument, string $deviceCodeEntity -> string $deviceCode. TBD later.
• Fix a bug where enabling the interval visibility is ignored:
  • RFC8628 Section 3.2
  • Fixes Add an option to always expose the interval param for the device code grant #1464
  • Even by explicitly calling $grant->setIntervalVisibility(true) the response still doesn't include interval. On the response you are excluding interval when it's set to default 5. Although the server may use the default interval value, we still want to include the internal on the response.
• Fix a bug where the new poll date is not persisted when slow_down error happens, because the exception is thrown before calling persistDeviceCode.
• Increase interval by 5 when slow_down error happens according to section 3.5 of RFC8628.
• Fix a bug where slow_down error response may have been returned even after the user has completed the auth flow (already approved / denied the request).
• Include the interval value on authorization_pending and slow_down error responses.

[Sephster]

@hafezdivandari apologies I've not forgotten about this. My partner is sick just now and my son has a sickness bug so I have little time but will get to it as soon as she is better. Apologies for the delay. Just wanted to give you an update

[hafezdivandari]

@Sephster No worries at all! Take all the time you need. I hope your family feels better soon.

[hafezdivandari]

Hi @Sephster, hope you’re doing well. Any progress on the PRs related to Laravel Passport? I’ve listed them all here.

[Sephster]

Thanks for this Hafez. I think there are some bugs that have been fixed here that aren't actual bugs. I'll try to outline them as best I can below:

• Fix typo is grand. Thank you!
• For a long time I debated whether to have a "setIntervalVisibility" function. Intially I just thought we could have the default as five and if you wanted to increase or decrease this, you could set the value to something different and we'd then report it in the response as the absence of it implies 5 seconds anyway. I think this is probably why the code is the way it is now but appreciate it is confusing to set visibility and then have it do nothing. I think the easiest fix here is to change the condition that adds the interval to the response to check for if the interval visibility has been set, which should be non-breaking.
• I think it is correct to not record a new poll date if we issue a slowdown. The slowdown message just informs the client they've polled too quickly. If we logged the poll date, we'd reset the timer to 5 second again which we don't want to do.
• The interval increase of five is supposed to be followed by the client, not enforced by the server so we shouldn't need to make a change here as far as I'm aware
• Can you highlight where the issue is with us returning a slow_down after the request has been approved? I wasn't too clear where this was happening
• Because we don't need to change the interval, we shouldn't need to report new interval values so don't need to include these in the error response, and can hopefully avoid these breaking changes

Hope all this makes sense but I think we probably only need to fix the visibility honouring and the typo. Cheers for all your work on this!

[hafezdivandari]

@Sephster I've applied the requested changes, please review again.