CNI networking cleanup support, Docker client robustness improvements

[twelho]

This PR includes a bunch of fixes and improvements around container and cache handling:

1. Remove the CNI networking of VMs post-run (52aa28d)
2. Make the cache exclude newly generated Objects without UID (872dcb8)
3. Improve the Docker client's parallel robusness by introducing fences (b58702c)
   -> you can now rm -f right after start -d without Ignite crashing

[luxas]

Thanks, will test in a moment

[luxas]

This PR currently depends on:

a) .status.containerID being added to the API #210
b) Patch support in the client #186

[luxas]

Oops, didn't mean to close it.

[luxas]

This got unblocked with #225.
You can now read the containerID using the v1alpha1.ignite.weave.works.containerID annotation for all
VMs started with ignite that is built off master.

In other words, you can now run the cleanup func client-side in Ignite when removing a VM using CNI networking, as you can read the containerID from the annotation.

[twelho]

This now includes the CNI networking cleanup work in 52aa28d, making the cache exclude newly generated Objects without UID in 872dcb8 and improving the Docker client's parallel robusness by introducing fences in b58702c (so you can now rm -f right after start -d without crashing).

[twelho]

You can now read the containerID using the v1alpha1.ignite.weave.works.containerID annotation for all

I decided to go for implementing an InspectContainer method in the client, which returns the ID among other details. As this method is used to check for container existence in RemoveVMContainer, I just took the ID from its result to remove the CNI networking with. IMO this is a more robust solution, as we just need a single lookup this way (container removal also uses this ID) and we eliminate the chance of the user accidentally editing the ID in the annotations. Check 52aa28d for the details.

[twelho]

@luxas is out of office, so as this is ready, going ahead and merging.