[FR] Built-in refresh token mechanism to achieve Silent Refresh and Better Workflow

The problem with the webhook mechanism is that it generates redundant requests for requests every time,
Therefore I choose jwt,
I'm writing an auth service, but I'm having a really big problem， I don't know how to implement silent token refreshing
In short, I have implemented auth service，but how to refresh jwt? I'm stuck.

I only have two choices now
1. Verify on the front end if the jwt is expired(decode without secret), and request a refresh token from the auth service if it is expired. ( But there may be time inconsistencies where the front end check has not expired, but by the time it reaches the back end it has expired，Therefore it is also necessary to set a lead time, and even then it is not a closed loop )

2. Request a token refresh based on the error returned by the graphql request. (Impossible to be insensitive)

Neither of these methods is particularly ideal，So I thought, could there be a built-in token refresh mechanism？
This can be achieved like this:

A . add 2 new configuration fields
```
// HASURA_GRAPHQL_JWT_SECRET
{
"refresh_token_path": "" // <---
"refresh_token_url": "" // <---
"type": "",
"key": "",
"jwk_url": "",
"claims_namespace": "",
...
}
```

B. When the jwt expires and the refresh_token exists, POST with refresh_token:string

C. RETURN a json with { token: new_token, refresh_token: new_refresh_token },

D. Hasura continue QUERY with the new token, send back RESULT and { token: new_token, refresh_token: new_refresh_token } as a cookie


This is more like a hybrid mode of jwt+webhook, where users can refresh jwt tokens senselessly
Then because cookies are used here to pass new tokens, they can also be captured on the front end via the graphql http link, becoming a completely senseless middleware

In this way, the front-end rarely needs to actively request auth service, the whole process is more reasonable