Pub/sub implementation

[zuiderkwast]

Special handling of commands "subscribe", "unsubscribe", "psubscribe", "punsubscribe", "ssubscribe", "sunsubscribe". These commands don't return anything apart from push messages, so they require special handling in the client implementation.

The commands mentioned above, when successful, don't return anything other than one push message per subscribed or unsubscribed channel. The pushed messages are passed to the push callback provided using the connection option push_cb. ered:command/3,4 returns {ok, undefined} for successful operation of these commands.

The representation of RESP-formatted pipeline commands is changed. This format is mainly used internally, but can also be passed to e.g. ered:command/3,4. The format is changed from {redis_command, non_neg_integer(), iodata()} to {redis_command, pipeline, [binary()]}.

Fixes #26

[zuiderkwast]

Questions:

• If the user has subscribed to a node, the node is gone and the cluster recovers, is a client expected to automatically re-subscribe using another node?
• If a slot is migrated and sharded pubsub is used, is a client expected to automatically subscribe to the new shard-channel owner?

... or we should at least document that we don't? ...

[bjosv]

Very nice. Does it affect throughput/performance in any significant way?

[zuiderkwast]

I haven't tested performance. We don't have any way to do that.