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

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.

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