ZooKeeper based discovery mechanism

As described in SLING-2939, an embedded ZK still is not optimal since
1. Still uses System.exit statements in its code
2. Requires Netty server dependencies (Sling ships Jetty)

• extra dependencies to manage / embed
• most probably requires to run on a new port

However, using ZooKeeper as discovery mechanism in a non embedded mode (dedicated infrastructure) still makes a lot of sense in large deployments. Indeed, considering that ZK is widely adopted in 3rd party products a large deployment would typically already deploy a ZK infrastructure which could be reused by a Sling discovery implementation.

Furthermore, in terms of efficiency (# of requests), a ZK discovery implementation is expected to score high as it provides an efficient (non polling based) mechanism for receiving notifications. This would guarantee a fast propagation of Sling instances properties and state.

This issue covers the implementation of the Sling discovery API based on ZK deployed in a dedicated infrastructure (not embedded)