When a socket timeout was set the sendall-like semantics was resulting
in losing information about sent data and raising socket.timeout exception.

The previous GreenSocket.send() implementation used to call fd.send() in a
loop until all data was sent. The issue would manifest if at least one
fd.send() call succeeded and was followed by a fd.send() call that would
block and a trampoline that timed out. The client code would see
socket.timeout being raised and would rightfully assume that no data was
sent which would be incorrect.

Discussed at https://github.com/eventlet/eventlet/issues/260.

In Python 3.5 subprocess.mswindows no longer exists. It is renamed to
subprocess._mswindows, I decided we don't really have to access that
now "private" attribute in order to know if we're on MS Windows.

On Python 3, GreenFileIO.write() now always write all bytes using a
loop, to have the same behaviour than GreenPipe.write() on Python 2.
Before, the write() could be partial, write less bytes than expected.

On Python 2, GreenPipe.write() doesn't allow partial writes, it
always write all bytes, even if the user requested an unbuffered pipe
(ex: by calling os.fdopen(fd, 'wb', 0)).

Modifying Python 2 to be pedantic and allow partial writes for
unbuffered pipes will likely break a lot of applications. It's
simpler to modify Python 3 GreenFileIO to behave the same than Python
2 GreenPipe.

This commit fixes the docstring which pointed
to the wrong class eventlet.queue.Queue instead
of the one in standard library.

Under certain conditions, if the WSGI iterable yields an empty string,
it can cause the response to be terminated.

The conditions are as follows:

  * no minimum chunk size (eventlet.wsgi.server() was called with
    minimum_chunk_size=0, or
    env['eventlet.minimum_write_chunk_size'] = 0)

  * chunked transfer-encoding on the response

In this case, if the WSGI iterable yields an empty string, then
eventlet.wsgi obligingly turns that into "0\r\n\r\n" and writes that
to the socket. This, of course, terminates the response as far as the
client is concerned. However, eventlet.wsgi doesn't notice, so it'll
happily keep calling next(app_iter) and sending the chunks.

If Connection: keep-alive is set, the client might then send the next
request, read some chunked response body, fail to parse it, and then
disconnect.

In other cases, either the 0-byte chunk is saved in the chunk buffer
until the minimum chunk size is met, or 0 bytes get written to the
socket. Those are both no-ops.

This commit discards 0-byte chunks from the WSGI iterable.

https://github.com/eventlet/eventlet/issues/243

- skip request body discarding when connection was to be closed anyway
- handle ChunkReadError while discarding, write to log, close connection

https://github.com/eventlet/eventlet/issues/27
https://github.com/eventlet/eventlet/issues/242