The loop over all possible IPv4 and IPv6 addresses turns out to also
loop through all possible socket types (SOCK_STREAM/IPPROTO_TCP,
SOCK_DGRAM/IPPROTO_UDP, SOCK_RAW/IPPROTO_IP).  This meant that each
connection attempt was repeated three times, serially.

This fixes new_addr.test nondeterministic failures.  Here's a short
reminder of what that test does:

  1. Starts a ZEO server on random port X
  2. Connects and creates some data
  3. Stops the ZEO server
  4. Starts a new ZEO server on random port Y
  5. Tells the old connection about the new address
  6. Makes a modification though a new connection
  7. Waits for the old connection to reconnect using the new address,
  8. Verifies that it sees the new data

Here's why the test used to fail:

  * In step 3, when we stop the ZEO server, the client would notice a
    disconnect and immediately try to reconnect.

  * Due to this bug it would open three TCP connections to localhost:X
    and somehow succeed (I've no idea why -- ZEO server is supposed to
    close the listening socket before it drops client connections, so
    how can a new connection to the listening socket succeed?)

  * It would try handshaking each of the connection one after the other,
    timing out after 10 seconds each time (in ZEO.ServerStub.stub).

  * Only after all three connection attempts failed would it sleep for
    `max_disconnect_poll` seconds and then try to connect to localhost:Y

  * Three times 10 seconds is 30 seconds, which is by accident the same
    timeout the test uses in step 7 to wait for a successful
    reconnection.

With this fix the test still does one unnecessary 10 second timeout
before it passes.  I'd love to fix it, but I'm losing hope of
understanding what's actually happening there.

LOL, Windows.

Hopefully this will make winbot happy.

`zip` is not used anywhere in this file (this is python-modernize/issue#6).

The builtin `map` works fine on both Python 2.x and 3.x, the way we use
it here, so there's no need to import it from `six`.

Instead of waiting for five arbitrary log messages let's wait for at
least two particular log messages, since the intent of this test is to
show that we're getting at least two of those.

by running tests in parallel.

See travis-ci/travis-cookbooks#155

In Python 3 r.write() returns the number of characters written.

It doesn't work, just results in no tests being run:
https://github.com/zopefoundation/zope.testrunner/issues/5

Attempting to open a file before it is created turns out not to be a
good idea.  Moved all the file opening inside the wait_until lambdas
(after extracting them into a standalone helper function, since you
can't use the with statement inside a lambda).

Also fixed test failure on Python 3.3 (r.write() returns the number of
bytes written).

Added an XXX about a possible hang while opening ClientStorage, in case
something went wrong.  I'm not sure how to fix that.

The tests fail without that version.

Timeout error showing up in log before the 'client has newer' error.

Match ZODB commit 69c18075dafca12a7bb4d431751d40c2f0f2884e.

Explicitly install the 'random2' dependency.

ClientStorage.py can deadlock in tpc_begin