XD-2097 Shutdown containers from admin

- Enable `shutdown` endpoint for containers
- Keep the `mangementContextPath` the same for both admin/container
- ContainerRegistrar stores the container's port as container attribute
- If the container uses local port `0` then the port is known only when
  the `EmbeddedServletContainer` is initialized
- Add `update` method in `ContainerRepository` to update the container data
- Update container data (attributes) along with container port info
- Add REST endpoint that shuts down container by `containerId`
- Get container host and port from container attributes
- Use `RestTemplate` to send `POST` request to shutdown the container
- Throw `NoSuchContainerException` if container is not found
- Add test

Handle error scenarios
- During `containerRepository.update` if the container path doesn't exist,
  throw `NoSuchContainerException`
- Add tests for `containerRepository.update` scenarios
- Check `zkConnection` before calling `containerRepository.update`
- Throw `ContainerShutdownException` when the response to shutdown container
  results in exception

Use the management port
- Use container server's `management` server port to access shutdown
  endpoint.
- Handle the `EmbeddedServletContainerInitializedEvent` when the event
  comes out of management server's servlet container. The namespace for this
  context is set to `management`. Hence using that to distinguish the event
- Make sure the management port is always updated when the above
  event is processed.
- Update the container attributes with mangement port (if used)
  before registering with ZK on the `ZKContainerConnectionListener`s
  onResume() and onConnect events
Added synchronization for container attributes

Changed ContainerAttributes internal map to ConcurrentHashMap
to take into account the possibility of multiple threads
reading & writing attributes.

When the admin port for a container is extracted from
an application context event, the port number will
be updated in the container's ephemeral node if the
node already exists. If the node does not exist, it
is assumed that the container is in the middle of
the registration process on another thread and therefore
the container attributes (including the management port)
will eventually be written to the container node.

The update to container attributes, check for node, and
update of node is now an atomic operation. Additionally,
the serialization of container attributes and subsequent
creation of the container node is also an atomic operation.
This guarantees that operations requiring read/write of
container attributes followed by a write to ZooKeeper
will happen on one thread at a time.

Improved assert message in functional test.