XD-2004: Containers stopped responding to Admin

Fixed race condition between the container creating the `/xd/deployments/modules/allocated/container-id` path and the supervisor removing the path when the container exits. The container will now wait for the supervisor to remove the path before proceeding with startup.

Added onSuspend and onResume to ZooKeeperConnectionListener. This allows us to distinguish between events where container ephemeral nodes need to be created after a network disconnect.

Temporary network disconnects will raise `SUSPENDED` events followed by `RECONNECTED` events. Containers will now avoid undeploying modules upon `SUSPENDED` events. `LOST` events still cause modules to be undeployed. `RECONNECTED` events will force a shutdown and recreation of the ZooKeeper client if the prior event was `LOST`. If the prior event was `SUSPENDED`, the container will re-register if the existing ephemeral node for that container was created by the previous ZooKeeper client session.

Testing was done on Linux via iptables DROP rules. Additionally, testing was performed with a ZooKeeper ensemble, including the shut down of 2 out of 3 servers to disrupt quorum.
In what case do you think this might happen? `NoNodeException` for the '/xd/deployments/modules/<containerId>` ?On an existing container, the `ModuleDeploymentsPath` is always created before the container is registered. Hence, the `ModuleDeploymentsPath` always exists. Maybe, when the DeploymentSupervisor initiates module deployment for the container that is departing and it's `ModuleDeploymentsPath` is already deleted?