Conflicts:
	src/ZEO/StorageServer.py

Fixed: SSL clients of servers with signed certs didn't load default

Asyncio cleanups

Optimizations, featuring prefetch

certs and were unable to connect.

Bye bye Promise.

Also fixed a comment.

Useful for playing with ssl configurations and generally for being
able to inspect server state in development and testing.

This only makes sense when running the server in a thread, of course.

Useful for playing with ssl configurations.

Also added a comment with a reminder for how to create self-signed certs.

Useful for playing with ssl configurations.

IOW, if there's an outstanding call is made for a given oid and tid,
and another call is made, the second call will use the result of the
outstanding call, rather than making another call to the server.

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