feat: LRU cache key

[ilteoood]

Closes #503

[simoneb]

Ok, the change is easy enough, but I wonder if there was a reason to hash it before storing it in the cache in the first place. The main thing I can think of is security, but the cache is in memory, so I'm not sure that's a valid assumption. Also, is avoiding the hashing really faster? I wouldn't expect the hashing to really slow down the whole thing.

[ilteoood]

I did the same question to myself and wasn't able to find the proper answer.
The only thing I thought was about avoiding collision, but different algorithms bring different keys.
Maybe it is just to avoid storing the user's key locally, which could contain sensitive data (like name, email..)

The hashing part btw makes it a bit slower. We should understand what's the right balance.

[simoneb]

I would not do this change until we discover why it was done in this way in the first place, and unless benchmarks show that it's much faster to do it without hashing the token.

[ilteoood]

I was thinking about giving the option to pass a hasher.
So if someone wants to use the identity hasher it is able to do so.
What do you think @simoneb ?

[simoneb]

Can you please expand the caching section to mention the performance implication of the default cache key builder and what to do to improve performance (i.e. use the identity function)?