feat: support refresh token

[aldbr]

This PR aims at solving https://github.com/DIRACGrid/diracx/issues/24

• [X] Add a new table for refresh token info to be stored in
  • Contains the minimum required information to generate a new access token from it
• [X] Return a refresh token with the access token from /auth/token
  • We always return a refresh token to the user, no matter the scope provided
• [X] Add support for the refresh token flow on /auth/token
• [X] Add a route for listing a given users refresh tokens
  • A user with the PROXY_MANAGEMENT property is able to get all the refresh tokens.
  • Other users can only see their refresh tokens
• [X] Add a route for revoking refresh tokens
  • A user with the PROXY_MANAGEMENT property is able to revoke any refresh token.
  • Other users can only revoke their refresh tokens
• [X] Implement refresh token rotation
  • We needed to force the commit in the DB for this specific case.

We also added a few tests:

• at the DB level:
  • insert, list, revoke
• at the route level:
  • Refresh token rotation mechanism
  • Refresh flow (expired refresh token, invalid signature)
  • List refresh tokens
  • Revoke refresh tokens

Questions:

Refresh token rotation: what if we commit while the revocation fails?

This does not happen, we first revoke the token:

• if there is no issue, we commit and then it is done
• else, the revocation process raises an exception, the commit is not done

What should happen if a user does the device_code flow multiple times in a row to get many pairs of tokens. Should we revoke the previous RT each time an interactive flow is triggered?

I would say that we should keep them all valid as they can be used for different purposes.