A take on re-implementing channels (WIP- don't merge)

This is WIP and not yet finished.

I was thinking over it and if we do transparent reconnects on the transport level, the callers will loose insight into this reconnection. For a loosely consistent system like eureka, we would need callers to know about reconnect to a different server. eg: the client when moving from one server to another would need some insights into handling conflicts when moving to a different server.

So, it will possibly be better to let the users of the `ServiceChannel` re-create a new channel on error and handle the semantics by themselves. A new channel creation will take into consideration the current state of the system (servers available/loaded) and create an appropriate connection. We should be using ribbon for this.

If we follow this model, the client `ServiceChannel` chooses a server at start (before doing any operations) and when the callers subscribe to it and there is a disconnect the error is propagated to the input of the `ServiceChannel`. This will make the caller create a new `ServiceChannel` and start over.