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 re-registration with ZooKeeper if the connection was previously `LOST` or if the container's ephemeral node is no longer present.

Testing was done on Linux via `iptables` DROP rules.
In this listener, `connectionState` is really the last known connection state reported to us by Curator. This state is maintained by us, not Curator. I think I could have picked a better name, such as `lastKnownState` to make this less confusing. I have some other changes I'm making so I'll also change this member name.

The reason why we have to maintain the last known state is because Curator raises a `RECONNECTED` event whether the previous event was `SUSPENDED` or `LOST`. It turns out the handling of `RECONNECTED` will vary drastically based on the previous state.

I'm going to close this PR and create a new one with the latest changes that I've made after testing with an actual ZooKeeper ensemble.