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.

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.

To allow test servers to shut down in a timely manner.

Also, some more debug logging.

Asyncio server

What it was testing is more sanely tested by the zeo-fan-out test.

Conflicts:
	.travis.yml
	setup.py
	src/ZEO/ClientStorage.py
	src/ZEO/cache.py
	src/ZEO/tests/testZEO.py
	src/ZEO/zrpc/client.py
	src/ZEO/zrpc/server.py

Also, removed load from the asyncion client implementation, since it
isn't used anymore.

Close opened-file leak in blob cache size check.

Closes #27.

Changed tests to not depend on ZODB underware

Zodb5

This is required (or maybe strongly implied) by the IStorage interface.

Also, rearrange the order of operations in _process_invalidations.

Each of these changes avoid a potential race when a connection starts
a transaction while invalidateTransaction is being called. Basically,
we don't want a connection to get a lastTransaction corresponding to
invalidations it hasn't processed.

This neither fixes nor provokes any test failures. :) The need for
this change was discovered via code inspection. It's hard to see how
to test the race without getting being insanely whitebox.

To avoid an error on tearDown.

Fix #22

Adding osx back.

Also adding back -j99, in hopes of getting quicker runs and making
travis nor hate us so much.  But then, we'll probably get more
failures. Maybe the best option will be to just make test pass even
when starved. :(

traviiiiiiiiis

A test was counting on a cache being written to, but it wasn't because
the storage got an invalidation later than expected (on suitably slow
machines, like travis and an AWS dev machine of mine).

that was making a test failure hard to interpret.