Conflicts:
	src/ZEO/ClientStorage.py

Implement iMultiCommitStorage

As it depends on getting serials from stpre or vote

ZEO's vote error handling was extremely and weirdly complicated.
There's a hysterical explanation: Originally, the ZEO protocol was
synchronous and mirrored the storage API. That was too slow, so store
was made asynchronous.  But then there was no way to return new
serials, so we added a serialnos client API that the server called
during TPC. This was used both to serials and errors.  Later, tpc_vote
was added, which is a synchronous method. That would have been an
execllent opportunity to fix this, but noooooooooo.

I'd like the server vote logic to get simpler, and we also want to get rid
of serialnos, as it makes it hard to commit multiple transactions at
once on the client.  We can't get rid of serialnos now, because the
client needs to work with old servers.

Of course, nothing is easy. There was a special edge case where if the
client saw an unhandled conflict error, it would invalidate it's cache
for that object, allowing it to eventually recover when caches had
missed invalidations. This required a change to ClientStorage, which
meant that the server wouldn't work with older ZEO versions, which
meant that the server could only support protocol Z5, which in tern
affected protocol-negotiation tests....

There are some cases where we want to touch the cache outside of the
I/O thread. Including:

- ClientStorage wants to to invalidata cache entries if it gets a
  conflict error in voting.

- loadBefore can probably be optimized by checking the cache in the
  client thread. (This will be safe for loadBefore, because the intent
  in practice is never to load current data.

This used to happen via the server calling serialnos, but ZEO 5
servers no longer do this.  For the reason for invalidating the cache
entry, see the new comment.

It's a shame that Tox is unable (or unwilling) to get test
dependencies from package meta data. :(

I develop on a mac (for better or worse) so I know that mac tests are being run.

- To make tests run faster with j99, and

- To isolate some tests that often seem to fail spuriously but pass
  when run by themselves.

And maybe avoid spurious test failures due to port contention.

It appeared that some tests were failing because servers weren't
closing down.  Modified the test forker module and the server to be
more paranoid about closing the server.

This seems to have helped test stability. (Or maybe I accidentally
fixed something while flailing :)).

Where we check for a disconnect, get disconnected and vote

Because running it single-threaded was unstable, at least in the tests.

See http://bugs.python.org/issue27392

SSL didn't work on Linux because of an incompatibility between
non-blocking sockerts and SSL (which wasn't an issue on Mac OS X for
some reason).

I decided to try switching the server to use a single thread.  This
led to a performance improvement for zodbshootout and a lower-level
networking test.  I refactored the server listening logic and kept (at
least for now) both the multi-threaded and the single-threaded
version. (The multi-threaded logic can be used by changing a single
import. Tests pass with both.).

I'm a bit worried about the asyncio server. See

  http://bugs.python.org/issue27386

Tests appear to be less stable using asyncio.server on my Mac. :(

So travis doesn't hate us.

Because we were computing the size info in the commit callback, which
might be before before the inderlying data were committed.  This caused the computation to be wrong in some cases.

Instead we get and send the size information after committing.