[REQ] Refresh token based on expiry before invoking request with expired access token

Is your feature request related to a problem? Please describe.

When invoking requests via the ApiClient generated for jersey2/3, the expiry date of the access token is not checked. This results in the resource server that is being talked to yielding a 401 error when the token is expired, which then triggers a refresh of the token (correct behaviour).

Describe the solution you'd like

We suggest to alter this behaviour so that the access token expiry is checked on the client side before a request is being sent, and (with a reasonable clock shift) if the token is invalid, refresh it with the refresh token first and then invoke the original request with a (now refreshed and valid) access token.

Describe alternatives you've considered

It would be possible to overwrite the mustache templates to introduce this feature on a by-project basis, however this would cause problems with upgradeability. We believe this feature would benefit the whole project so it would make sense to implement it at the source.

Additional context

Relevant code section

According to The OAuth2 specification skipping the "faulty" request that yields a 401 error with the expired token is allowed if the client knows the token is expired, which means checking beforehand would still be within the specification.

Start with the linked Java jersey3 ApiClient.mustache section around line 1278, then compare the corresponding jersey2 template and their existing token-refresh flow. The change is complete when expiry is checked before sending the request, an expired token is refreshed first, and the original request proceeds with the refreshed token without the avoidable 401.