Problems with the Attach API implementation

This is the same as awslabs/aws-sam-cli#1551

We hit that first, then doing the investigation we realised that the same might be true for docker-py.

The gist is that when pilfering the socket descriptor in

https://github.com/docker/docker-py/blob/a0b9c3d0b38abd4af1880ca3dde2845556dd2f70/docker/api/client.py#L310

the subsequent

https://github.com/docker/docker-py/blob/a0b9c3d0b38abd4af1880ca3dde2845556dd2f70/docker/utils/socket.py#L74

might end up trying to read from a socket which is already at EOF because all the muxed binary protocol data has been swallowed by the 8KB pull-up done by the requests.Response object when reading the response to the POST /containers/.../attach?...

The thing is that when taking ownership of the underlying socket it's also necessary to collect what's possibly left in the requests.Reponse input buffer and start consuming all of that before reading from the socket.

(FYI, there is a proof-of-concept fix attached to awslabs/aws-sam-cli#1551)

Start with docker/api/client.py around the socket descriptor handling and docker/utils/socket.py around socket reads, then compare the POST /containers/.../attach response path with the proof-of-concept referenced in awslabs/aws-sam-cli#1551. Done means attach reliably consumes any buffered response data before reading the underlying socket, including when the socket is already at EOF.