camellia-redis-proxy对于发布订阅命令的增强（Key-space notification 和 Key-event notification）

[caojiajun]

对于发布订阅中的订阅请求，目前proxy的逻辑如下：
1、如果后端路由是redis-standalone或者redis-sentinel，则会绑定一个到后端redis节点的连接，透传所有的订阅消息
2、如果后端路由是redis-cluster，则会随机选择一个节点，再执行1）中的操作（如果是ssubscribe，则会哈希到特定节点）
3、如果后端路由是读写分离的配置，则pub命令会发给所有的写地址（也就是支持双写），sub命令只会建立到第一个写地址的连接
4、如果后端路由是一个自定义分片，则会报错不支持
5、此外，如果开启了ConverterProxyPlugin，则channel会被当作key字段进行转写，转写方法可以由业务方自定义（如增加前缀）

对于keyspace notifications，包括两种类型：
1、Key-space notification
2、Key-event notification

参考：keyspace-notifications

目前遇到的问题：
1、Redis keyspace notifications，如key过期事件等，也是依赖pubsub来实现的，并且不同于普通的channel，在redis-cluster集群中，消息是不会广播的。当redis-cluster挂在proxy后端，而proxy又被当作单点redis对外提供服务时，客户端会发现订阅keyspace相关的channel能成功，但是却不完整（因为proxy只建立了到后端的一个连接）
2、后端redis可能不支持keyspace功能，如各种redis兼容的kv存储（如 kvrocks 、 pika 、 tendis 等）

待讨论的方案：
1、对于问题1，可以在后端是redis-cluster时，并且订阅的channel是keyspace相关频道，则proxy订阅所有节点，聚合后再返回给客户端
2、对于问题1和问题2，还有一种方式，当订阅channel是keyspace相关频道，不再透传给后端，而是proxy拦截处理，这种方式需要处理如下几个问题：
1）proxy节点之间需要共享一下订阅信息，因为一个keyspace的notifications事件源头可能是其他proxy节点的请求
2）对于key过期这种事件，需要维护key的ttl状态，维护开销需要确认

[caojiajun]

related issues #213