default. You must pass a log option specifying a log file name.

Uvloop

uvloop is a bit faster than the standard asyncion event loop.

Unfortunately, there's an issue with the ZEO tests and using uvloop in
the ZEO server:

  https://github.com/MagicStack/uvloop/issues/39

Fortunately, most of the performamce benefits of using uvloop seems to
be in the client.

For now, we'll just use ivloop on the client side, as the incremental
effort of using it in the server aren't worth futher wrestling with
the tests. (I spent quite a bit of time just narrowing down the cause
of the test issue.)

With this PR, if uvloop can be imported, it will be used for the
client. (uvloop requires Python 3.5 or later and doesn't support Windows.)

Dont pickle errors

Don't send errors as pickles. Send error names and class dict or arguments.

This is a step toward eliminating instance pickles from the ZEO protocol.

This is much messier than I'd like it to be because of the way both
python and ZEO handle exceptions.

Server sync

try caching again, off on a separate branch.

Conflicts:
	CHANGES.rst

- The ZEO server register method now returns the storage last transaction

Conflicts:
	CHANGES.rst

Client disconnect errors are now transient errors.

Apparently, travis doesn't want to test this branch. :(

And slightly with pip installing buildout (rather than bootstrapping).

They're annoying. :)

  transaction, allowing the client to avoid an extra round trip during
  cache verification.

server_sync constructor argument to force a server round trip at
the beginning of transactions to wait for any outstanding
invalidations at the start of the transaction to be delivered.

Because ZODB 5 no-longer does

  applications retry jobs that raise transient errors, jobs (e.g. web
  requests) with disconnect errors will be retried. Together with
  blocking synchronous ZEO server calls for a limited time while
  disconnected, this change should allow brief disconnections due to
  server restart to avoid generating client-visible errors (e.g. 500
  web responses).

Zeo4 server support

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.