ZEO4 servers can send invalidations out of order with
``getInvalidations`` results, presumably because ``getInvalidations``
didn't get the commit lock.  ZEO4 clients worked around this (maybe
not directly) by queuing invalidations during cache verification.
ZEO5 servers don't send invalidations out of order with
``getInvalidations`` calls and the ZEO5 client didn't need an
invalidation queue, except they do need one to work correctly with
ZEO4 servers. :/

The later seems to be necessary when running the test multiple times
in a test run (as I did while debugging a test failure).

It turns out the ZEO4 server doesn't shutdown cleanly in tests without
a shorter timeout (like the one I added for ZEO5).

For now, this is just in the copy used in the ZEO5 tests.  If I have
to updatre the copy at some point (hopefully not), then I'll add this
to ZEO4 proper.

To avoid spew about threads being left behind by tests.  The normal
multi-processing.Queue uses a thread to send data and the machinery
for stopping this thread seems to be buggy (or inscrutable) on Linux,
causing test runner spew that made output hard to interpret.

Added an option to test the ZEO 5 client against the ZEO 4
server. This involved making a copy of the ZEO 4 server in
ZEO.tests.ZEO4 and disabling tests of ZEO5-specific features.

Testing revealed bugs in support for ZEO 4 servers, which were fixed.

Added an option to test the ZEO 5 client against the ZEO 4
server. This involved making a copy of the ZEO 4 server in
ZEO.tests.ZEO4 and disabling tests of ZEO5-specific features.

Testing revealed bugs in support for ZEO 4 servers, which were fixed.

Added the ability to pass credentials when creating client storages.

This is experimental in that passing credentials will cause
connections to an ordinary ZEO server to fail, but it facilitates
experimentation with custom ZEO servers. Doing this with custom ZEO
clients would have been awkward due to the many levels of
composition involved.

In the future, we expect to support server security plugins that
consume credentials for authentication (typically over SSL).

Note that credentials are opaque to ZEO. They can be any object with
a true value.  The client mearly passes them to the server, which
will someday pass them to a plugin.

Especially splitting the method used to send invalidations and info,
since we no-longer send both in the same call.

If a transaction only adds objects (like the transaction that ZODB.DB
uses to create the root objects, we still need to send invalidations so clients see the new tid, because MVCC.

That was causing test failutes when using the multi-threaded server.

Test cleanup 2016 7 8

Rehabilitate mtacceptor

Simplify server commit lock management

Conflicts:
	src/ZEO/StorageServer.py

Fixed: SSL clients of servers with signed certs didn't load default

Asyncio cleanups

Optimizations, featuring prefetch

(There seems to be a resource issue with Python 2, that I might run
down some time.)

Mainly for tests.

Also, add a constructor option to use a custom acceptor.

The new api will be in Python 3.6, and hopefullt, in uvloop soon.

When binding to port 0, make sure we set our address to a 2-tuple, because
IPV6 4-tuples confuse ClientStorage.

certs and were unable to connect.