Conflicts:
	setup.py
	src/ZEO/asyncio/base.py

Uvloop

Conflicts:
	setup.py

Client side conflict resolution

TCP_NODELAY

Conflicts:
	setup.py
	src/ZEO/tests/protocols.test

See: https://github.com/zopefoundation/ZODB/issues/84

I'm losing my love of stubs. :(

Conflicts:
	src/ZEO/ClientStorage.py
	src/ZEO/StorageServer.py

Add SSL support +

It's sad no reviewer, but I suppose it can be reviewed even after a merge.

I'd missed that you could get a transport's socket using get_extra_info.

Conflicts:
	src/ZEO/ClientStorage.py

Implement iMultiCommitStorage

This is a nasty work around for: https://bugs.python.org/issue27456

It can't always be applied.  For example, it can't be applied to Linux
SSL sockets using the asyncio-provided loop.

Conflicts:
	src/ZEO/ClientStorage.py

And holy crap, uncommented some tests that I'd commented early while
working on asyncio and forgot to uncomment before checking in.

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.