Closes https://github.com/eventlet/eventlet/issues/295 (in the wsgi
module we use a custom writelines implementation now).

Those write() calls might write only part of the data (and even if they
don't - it's more readable to make sure all data is written
explicitly).

I changed the test code so that the write() implementation returns the
number of characters logged and it cooperates nicely with writeall()
now.

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

The sendto() interface as defined in Python documentation:

    socket.sendto(string, address)
    socket.sendto(string, flags, address)

I didn't catch the fact that [1] broke this, this patch fixes it and add
a sendto/recvfrom test to make sure it doesn't happen again (turns out
we didn't have any).

GitHub issue: https://github.com/eventlet/eventlet/issues/290

Fixes: bc4d1b5 - gh-274: Handle blocking I/O errors in GreenSocket

[1] bc4d1b5d362e5baaeded35b1e339b9db08172dd2

I hope I didn't miss anything/anyone.

The original commit[1] was not enough because we run tests using tox and
tox by default doesn't pass all environment variables to the
environments in which tests run - this patch whitelists subset of
environment variables set by Travis, including one that we read and use.

[1] 74f418bcf38ac128cadad641d59d7ecd8f127340

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.

The original commit[1] has been reverted because it broke the
test_multiple_readers test. After some debugging I believe I more or
less know what's going on:

The test uses sendall() which calls send() in a loop if send() reports
only part of the data sent. Previously sendall() would call send() only
one anyway because send() had sendall-like semantics; send has an
internal loop on its own and, previously, it'd call the underlying
socket object send() and, in case of partial write, call trampoline
mechanism which would switch to another greenthread ready to run.

After the change partial writes no longer result in trampoline mechanism
being called which means that during this test it's likely that
sendall() doesn't yield control to the hub even once. Similarly the
current recv() implementation - it attemps to read from a socket first
and only yields control to the hub if there's nothing to read at the
moment; when one of the readers obtained control it's likely it'd manage
to read all the data from the socket without yielding control to the hub
and letting the other reader receive any data.

The test changes the sending code so that it not only yields to the hub
but also waits a bit so that both the readers have to yield to the hub
when trying to read and there's no data available; the tests confirmed
this lets both the readers receive some data from the socket which is
the purpose of the test.

[1] 4656eadfa5ae1237036a63ad4004dbee4572debf