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

  with regard to the load lock.  This allowes ZEO to work with the
  upcoming ZODB 5, which used loadbefore rather than load.

  Reimplemented load using loadBefore, this testing loadBefore
  extensively via existing tests.

Use a timeout argument in a test to avoid waiting too long when demonstrating ClientDisconnected errors

Removed an odd test that tested for an implementation-specific
(afaict) regression.

To see if we can get tests to pass in travis.

Otherwise, we may fail to connect on some platforms.

If a protocol was disconnected while registering, maybe because the
server was still starting, the disconnection was handled correctly by
the Client, because the protocol attribute wasn't set, the connection
wasn't retried.