Consider migrating away from the use of "refresh_token_expires_at"

[pcurtisrab]

Currently Dr. G is using the refresh_token_expires_at claim to capture the expiry date of the refresh token. The alternative is to use the exp value from the token introspection endpoint.

While this has the advantage of being provided in the id_token response (negating the need for a call to the introspection endpoint), it has the disadvantage of being contentious from a standards point of view. In the future there may be Data Holder implementations that take issue with the request for refresh_token_expires_at.

An even simpler alternative is to not check the introspection endpoint either, and simply assume that the refresh token expires in 28 days or the end of the sharing duration (whichever is earlier)

[pcurtisrab]

We should probably also remove refresh_token_expires_at from the default list of "mandatory" claims for the id_token. Given it's mandatory in one place but not in the other, this could have unpredictable results.