Malevolent users may decide to only - and repeatedly - present an otherwise
valid refresh token, causing the issuance of a new access tokens everytime,
likely along with new refresh tokens, causing many ZODB writes.
Avoid this by pushing the token expiration date by one lifespan accuracy,
so there can only be one write per session per lifespan accuracy period.

That way, we do not require creation of a login at all to use OAuth.

By default, refresh tokens generated using OAuth2 can be used as long as they
are valid. This commit introduces an option, which, when enabled, makes it
impossible to use already-used refresh tokens.

Factorize standard `token` method to implement a protected `tokenInternal`
method that allows getting a token for an user as Manager.

`createSession` method from the OAuth2 Authorisation Server Connector needs
to access client value. Fetching this value from the session is not needed
since it is already stored in a local variable.

When an error was encountered in `jIOWebSection`, it did not abort the
transaction, as it usually does in ERP5. This was made on purpose because
errors are logged in ZODB, hence aborting the transaction didn't make it
possible.

This behavior was annoying, so this commit purposedly abort transaction before
starting a new one to handle error. We are therefore able to log error in ZODB
while also keeping the usual ERP5 behavior of aborting on error.

Unindex, create and drop are managed by catalog

As it is the string, make it of fixed string

As get and put actions are deterministic there is no need to loop
over various schemas when checking data. If there is an error it is
returned directly.