This is experimental in that passing credentials will cause
connections to an ordinary ZEO server to fail, but it facilitates
experimentation with custom ZEO servers. Doing this with custom ZEO
clients would have been awkward due to the many levels of
composition involved.

In the future, we expect to support server security plugins that
consume credentials for authentication (typically over SSL).

Note that credentials are opaque to ZEO. They can be any object with
a true value.  The client mearly passes them to the server, which
will someday pass them to a plugin.

Especially splitting the method used to send invalidations and info,
since we no-longer send both in the same call.

If a transaction only adds objects (like the transaction that ZODB.DB
uses to create the root objects, we still need to send invalidations so clients see the new tid, because MVCC.

That was causing test failutes when using the multi-threaded server.

Test cleanup 2016 7 8

Rehabilitate mtacceptor

Simplify server commit lock management

Conflicts:
	src/ZEO/StorageServer.py

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

Asyncio cleanups

Optimizations, featuring prefetch

(There seems to be a resource issue with Python 2, that I might run
down some time.)

Mainly for tests.

Also, add a constructor option to use a custom acceptor.

The new api will be in Python 3.6, and hopefullt, in uvloop soon.

When binding to port 0, make sure we set our address to a 2-tuple, because
IPV6 4-tuples confuse ClientStorage.

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.