Handle scenario of lulu refresh token not expiring
Context
There is a possibility that refresh token expiration is set to 0, ie. that it never expires.
The current implementation in Ketida, on acquiring a refresh token, it would set a job to run on its expiration time, which would end up reverting the "connected" ui on the client to the "connect to lulu" button, effectively asking the user to sign in again.
Proposal
We need to enhance the implementation to handle the scenario where this would never happen.
Implementation
If the refresh token is invalidated, the user will be allowed to perform an action (refresh token is not considered expired), the action will fail (refresh token has been invalidated) and the ui will return to its "connect to lulu" state. (this is the same flow as when a refresh token gets invalidated before its expiration time on lulu's end)
If the value received for the expiration time is 0, no assumptions will be made concerning how long it will be valid for. When it becomes invalidated is handled on Lulu's end, and will fall back on the flow described in the paragraph above if and when it happens.
[A description of the steps to implement the feature.]
Alternative approaches (if applicable)
[Include any alternatives to meet this use case.]