- make the locked decorator easier to inline by not creating a new closure every time.
- use builtin dicts instead of the pure-python BTrees (only under pypy)

"Transaction",                  AFTER    BEFORE
"Add 3000 Objects",             10014      8777
"Update 3000 Objects",          12199      8805
"Read 3000 Warm Objects",        4294      3699
"Read 3000 Cold Objects",        4264      3676
"Read 3000 Hot Objects",        79764     58732
"Read 3000 Steamin' Objects", 2667283   2574508

Rollback some test changes now that Python persistent handles registration during __setstate__ the same way C persistent does.

After study, the delayed release of iterators under PyPy seems harmless. Move the gc calls that clear them to the test case.

Get status information via the zeo port and a nagios monitor

So we don't have to worry about incomplete sends or recvs.

the ZEO port without creating a full-blown client connection and
without logging in the server log.

- Support new Python versions.

[ci skip]

Before Python 3.4, the logging module registered them in both
directions, but quit doing so in 3.4, breaking doctests which expected
to display custom level name ("BLATHER").

See: http://blog.travis-ci.com/2014-12-17-faster-builds-with-container-based-infrastructure/

Add server side logging for MTDelay

Log level INFO

20 minutes to read the code in order to find where to set the log level :) 
Hope to help other people ;)

In my experience bootstrap.py wants the latest setuptools and it wants a
distribute egg.  Asking for the latest distribute should give us both.

Use os.urandom() to read from /dev/urandom

The loop over all possible IPv4 and IPv6 addresses turns out to also
loop through all possible socket types (SOCK_STREAM/IPPROTO_TCP,
SOCK_DGRAM/IPPROTO_UDP, SOCK_RAW/IPPROTO_IP).  This meant that each
connection attempt was repeated three times, serially.

This fixes new_addr.test nondeterministic failures.  Here's a short
reminder of what that test does:

  1. Starts a ZEO server on random port X
  2. Connects and creates some data
  3. Stops the ZEO server
  4. Starts a new ZEO server on random port Y
  5. Tells the old connection about the new address
  6. Makes a modification though a new connection
  7. Waits for the old connection to reconnect using the new address,
  8. Verifies that it sees the new data

Here's why the test used to fail:

  * In step 3, when we stop the ZEO server, the client would notice a
    disconnect and immediately try to reconnect.

  * Due to this bug it would open three TCP connections to localhost:X
    and somehow succeed (I've no idea why -- ZEO server is supposed to
    close the listening socket before it drops client connections, so
    how can a new connection to the listening socket succeed?)

  * It would try handshaking each of the connection one after the other,
    timing out after 10 seconds each time (in ZEO.ServerStub.stub).

  * Only after all three connection attempts failed would it sleep for
    `max_disconnect_poll` seconds and then try to connect to localhost:Y

  * Three times 10 seconds is 30 seconds, which is by accident the same
    timeout the test uses in step 7 to wait for a successful
    reconnection.

With this fix the test still does one unnecessary 10 second timeout
before it passes.  I'd love to fix it, but I'm losing hope of
understanding what's actually happening there.