There is something special about starting a container via POST /containers/(id)/start:
If the posted message body is not empty, any previous container customization will be reset to its defaults.

To illustrate, here are two variants of creating a container with custom DNS and then starting it.

# OK
$ id=$(docker create --dns 8.8.8.8 nginx)
$ curl -XPOST -H 'Content-type: application/json' http://localhost:2375/containers/$id/start -d '{}'
$ docker inspect -f '{{ .HostConfig.Dns }} {{ .State.Running }}' $id
[8.8.8.8] true

# DNS setting gets lost by setting Privileged.
$ id=$(docker create --dns 8.8.8.8 nginx)
$ curl -XPOST -H 'Content-type: application/json' http://localhost:2375/containers/$id/start -d '{"Privileged":false}'
$ docker inspect -f '{{ .HostConfig.Dns }} {{ .State.Running }}' $id
<no value> true

Because docker-java currently includes lots of parameters in its StartContainerCmdImpl, there is no way to just start a preconfigured container, see the newly added StartContainerCmdImplTest.existingHostConfigIsPreservedByBlankStartCmd() that fails with the current implementation.

This PR solves the issue by introducing a notion of undefinedness for all parameters and ignoring all empty parameters when serializing.

Thus, dockerClient.startContainerCmd(container.getId()).exec() will send {} as message body.