Implementation of refresh-token support

[j-chmielewski]

Currently, Avanguard, after verifying the TOS signature, returns a token that is valid for a week. This prevents the invalidation of tokens. To enable token blacklisting & refreshing:

 After verifying the signature, TOS Avanguard returns two tokens:

      Identity token: used by the client in further communication, the proxy verifies it cryptographically with each request, decoded contains information about the client (mainly the wallet address). Validities: 4h.

     Refresh token: Used by the client to fetch a new identity token when it expires. When downloading a new identity token, the blacklist is checked. If the refresh token is blacklisted, we refuse to issue a new identity token. Validities: 24h.

 Each time after refreshing the token, Avanguard returns both a new identity token and a refresh token (thanks to this, if the user uses the site a lot, he will not be forced to sign the TOS again)

 If the client does not have a current refresh token, he must re-sign the TOS.

 Frontend saves identity token in cookie, refresh token in local storage. When the identity token expires, the frontend uses the refresh token to fetch new tokens and saves them.

Chage data model and add status if token is valid/blacklisted, if is in blacklisted state do not refesh the token

Acceptance Criteria:

• all the tokens expiration time can be set by ENV variable during deployment
• there are detailed logs in DEBUG
• there are business logs (token XYZ was refreshed, blacklisted, ,.,.,.) in INFO