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.

Load uses load before