EVEREST-1925 Blocklisting mechanism

[oksana-grishchenko]

Problem:
When user logs out, their token remains valid until its natural expiration time specified in the token itself. For the built-in Everest authentication the token lifetime is 24h which introduces security concerns even though the built-in authentication is not recommended for the production use.

Solution:
Implement the blocklisting mechanism according to the proposal

This PR does:

• Add the new DELETE /session endpoint, which adds the current token information to the blacklist
• On each request, check the blacklist and reject the request if the token is blacklisted. The check uses cashed data, so no overhead is added in terms of additional k8s requests.
• Add mechanism to cleanup the blacklist - each time a new value needs to be blocklisted we cleanup outdated data from the list
• Add mechanism to cache the blacklist. Initially, the idea was to use the controller-runtime cache, however since the blocklist secret is managed by everest-server only and is not touched by any external components like cli, there is no need to watch the secret changes using mechanisms like informer, because we know for sure when an update happens and can update the cache.
• Add rate limit for the DELETE /session endpoint. The rate limiting rule which was applied to the POST /session endpoint is now applied to the DELETE /session as well, for more details see EVEREST-1157 Add /session rate limits #530

[oksana-grishchenko]

the endpoint already can return 429 status, but it wasn't reflected in the API spec