Docker daemon threads can become affixed to a container's network namespace, causing network errors later when the container is stopped (default network)

This is very similar to https://github.com/docker/libnetwork/issues/1113, which concerns the embedded DNS server in non-default networks. However, running our repro script based on the repro provided in https://github.com/docker/libnetwork/issues/1113, we're able to observe the same effect (daemon threads in a container's network namespace) while using a default network.

We've tested this in a few different configurations, and have the following results:

• Docker 1.11.0 as released, Go 1.5.3, GOMAXPROCS unset: 73 failures/2000 runs, 3.6% failure rate
• Docker 1.11.0 + patch from https://github.com/docker/libnetwork/pull/1115, Go 1.5.3, GOMAXPROCS unset: 76 failures/2000 runs, 3.8% failure rate
• Docker 1.11.0 + patch from https://github.com/docker/libnetwork/pull/1115, Go 1.5.3, GOMAXPROCS=1: 482 failures/1900 runs, 25.3% failure rate
• Docker 1.11.0 + patch from https://github.com/docker/libnetwork/pull/1115, Go 1.4.2, GOMAXPROCS unset: 463 failures/2000 runs, 23.1% failure rate
• Docker 1.11.0 as released, Go 1.4.2, GOMAXPROCS unset: 407 failures/2000 runs, 20.3% failure rate
• Docker 1.9.1, Go 1.4.2, GOMAXPROCS unset: 21 failures/1900 runs, 1.1% failure rate

These tests were all run on Amazon EC2 instances running the Amazon Linux AMI on a mix of different instance types.

From these results, it looks like it has been a problem for a while, but got worse more recently.

Start by running the linked repro script against the default network, then compare its behavior with libnetwork issue 1113 and pull request 1115. Trace how daemon threads remain in a container's network namespace across stop operations; done means the reproduction no longer leaves those threads affixed or causes subsequent network errors.