Client side refactoring

-- Introducing a EurekaClientRegistry which feeds to all users of the client.
-- Separated eureka-server, eureka-read-server and eureka-write-server
>>> Our protocol semantic does not require waiting for ack

But we do overwrite interest set on every upgrade, so it is required that we do not interleave two upgrades. Consider this scenario:

time t1 -> Register Interest Vip1
time t2 -> Upgrade Interest Vip1 + Vip2
time t3 -> Upgrade Interest Vip1
time t4 -> Upgrade Interest Vip1 + Vip3

If we do not sequence send on these upgrades (which is what this code is trying to do), `InterestChannel.upgrade()` can be interleaved and hence time t3 operation may happen after time t4 operation thus overriding the interest set. 

In essence we need to make sure that write on the connection is sequenced as opposed to an async send which the `InterestChannel` does. Once we enqueue write in the correct order, netty + tcp makes sure that the order is maintained.