make docker daemon initiated container (re)start work properly

[rade]

The docker daemon can decide to (re)start containers, e.g. after a reboot or when a --restart policy was specified for the container.

We want this to work properly for a) the weave container and any similar weave infrastructure containers (such as weavedns), b) application containers. In the latter case this would entail re-attaching to the weave network, and re-registering with weavedns.

This does require bits of #230/#312/#117.

[bboreham]

It would be nice if the container came back with the same IP address after a restart, as described in #1047.

[rade]

Presumably any containers started via the proxy will hang in weavewait when restarted by docker.

The proxy, or a separate container, could take care of re-attaching containers. This won't work on docker restart though, since the proxy may not be running yet. Though I guess we could scan all containers on proxy startup and attach any that are weavewait-ing.

[bboreham]

This won't work on docker restart though, since the proxy may not be running yet

The Docker Event mechanism allows clients to fetch events from before the time they were started, so this is not an issue.

Doing that brings a different issue: what if the proxy itself is restarted, and queries for past events, and thus gets told of the start of containers that it already attached to weave (before the proxy was restarted)?

Maybe we can rely on attachment being idempotent, or maybe we can check before attaching.

[bboreham]

The fix in #1210 does not do (a) in the original description - dealing with restart of weave itself.
So there is an extra fix in #1359 for that part.