Add caching to internal bcrypt authentication

[mattrafuse]

Since bcrypt provides a high level of security, we'd like to continue to use it for authentication. However, since it is known to be extremely slow, we should cache the authentication result after the first authentication attempt.

The design would look something like:

irst auth attempt should use the bcrypt module to check the integrity of the given API key. If successful, cache the result in redis (details to follow). If a failure, cache nothing. This provides protection against brute-forcing attacks while speeding up future authentications.

[simonbjorzen-ts]

Additional context:

When the API is experiencing high throughput, we experienced significant slowdown of the API.
This was caused by the API key authentication validating the bcrypt hash for every authentication attempt.
Bcrypt is slow by design and requires a lot of CPU cycles just to validate the hash.

The solution for this is to implement a cache in redis that stores the API key secret in HMAC-SHA256 hashed format.
This is by design lower security then that of Bcrypt, but since the API keys are not created by user input, but instead randomly generated long strings with high entropy, HMAC-SHA256 is perfectly fine.

As an additional security measure, we keep this hash in the volatile redis instance, so that it is always only kept in-memory and never written to disk.