In working on the next iteration of the lock manager to provide
object-level locking, I realized:

- It was saner let all waiting try to get locks when locks are
  released, at least in the more complicated logic to follow.

- We really do almost certianly want a multi-threaded server, even if
  it doesn't run faster (still an open question), because otherwise,
  big commits will completely block loads.

- We don't really want to hold the lock-manager lock while calling the
  callback.  Again, this really only matters if we have a
  multi-threaded server, but it also feels like a matter of hygiene :)

I decided to rework this branch:

- Don't hold lock-manager internal lock when calling the callnack.

- When releasing the lock, use call_soon_threadsafe to let all waiting
  have a chance to get the lock.

- A little bit of factoring to DRY. (This factoring will be much more
  useful in the follow-on branch.

This rework restores the workability of the thread-per-client model.

Because races

And move this file to the top of the project, as there was a similar
version ther.

Python 2 support

After reading run_until_complete doc :)

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