Use a timeout argument in a test to avoid waiting too long when demonstrating ClientDisconnected errors

Removed an odd test that tested for an implementation-specific
(afaict) regression.

To see if we can get tests to pass in travis.

Otherwise, we may fail to connect on some platforms.

If a protocol was disconnected while registering, maybe because the
server was still starting, the disconnection was handled correctly by
the Client, because the protocol attribute wasn't set, the connection
wasn't retried.

To turn on debug logging.  A lot of interesting information helpful
when debugging network-implementation issues is logged (because
threads).

These errors were actually hidden by the test, but were annoying when
debug logging was enabled.

In ZEO.asyncio.client.Protocol.data_received, the logic was broken if
there we unhandled errors, for example in calling client storage methods.

Because normally the tests are much less patient than real life.

Some test timeouts are very low to make the tests go less slow, but
sometimes we need to wait longer.

Timeout default was False, which must have resulted from an editing
error, but we failed to pass it through where it was needed
anyway. Fixed now.

When changing addresses (think ZooKeeper :) ), we needed to be more
careful about current connection status. If we're still trying to
connect, we should stop and start over with the new addresses.

And also, we no longer do old-style cache verification.

We'll eventially deprecate the old zeo configuration, as it's
implemented in the wrong package. :) A new implementation will provide
poll-interval, however, there's not much point in configuring that.

Need to check for None as data value.

And make waiting for reconnect a little easier.

We were sending lastTransaction requests while register requests were
in-flight.  If register failed, then the lastTransaction request was
invalid, causing the connection to be closed. :(

When we update the server, we'll have register return lastTransaction
and probably info, since the client wants that information on connect.

To make matters worse, when the other site closes a connection, None
is passed to protocol connection_lost methods, which was fouling up
sornstream error detection.

Because it's only accessed by the asyncio thread.