Implement client side caching

[holykol]

This PR implements server-assisted client side caching introduced in Redis 6.0

This is done entirely at a pool level by running a separate goroutine that subscribes to invalidation broadcasts.
Command responses are, again, cached by middleware at a pool level.

This is done via new Cacher struct in redisx package.

TODO:

• Cache size limit
• Broadcasting mode
• Opt-in caching (via Matcher)
• Keeping track of TTL

closes #513

[holykol]

Can someone review?

[stevenh]

Given not everyone will be using caching and in fact redis 6 for some time, I'm wondering if this should be implemented by a separate sub package?

This would ensure we don't bloat the core pool code with features not everyone will use or want.

What do you think?

[holykol]

@stevenh Great idea. I'm a little embarrassed I haven't thought of that before I started trying to fit more code into redis.Pool. Give me some time.

[holykol]

Didn't mean to close this, but fine. Take a look at now @stevenh

[holykol]

OK, I've gave up on trying to come up with abstraction for caching other data types. It's too much work for potentially useless feature:

1. Implementing this feature basically means re-implementing big chunk of Redis functionality locally.
2. Hashes, lists and sets change too fast to benefit from caching.
3. My guess is that most people using Cacher will just store json/protobuf/gob/bare serialized data structures and will not care about other types.

@stevenh Can this be merged with it's current feature set?

[stevenh]

Just a quick note to say I haven't had chance to look at this yet, hopefully soon