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.
This was added while debugging XD-2004. The details are fuzzy for me, but basically there was a race condition where the path didn't exist when it should have (as you describe above). It might have been due to a container departing and rejoining right away and the supervisor deleting the path as part of its processing of the container departed event.

To answer your question, this should never happen now because of the fixes in this PR - but if it does then we will at least see exactly which path it was that we were expecting.