+ Transaction T1 deletes some of the keys in bucket B,
  but not all of the keys.

+ Transaction T2 deletes (exactly) the keys in B that
  aren't deleted by T1.

The version of B each transaction sees is then non-empty,
but conflict resolution creates an empty bucket.  However,
conflict resolution doesn't have enough info to unlink an
empty bucket from its containing BTree correctly.

The result is that an empty bucket is left in the BTree,
which violates a BTree invariant.  The most probable
symptom is a segfault, when later & unrelated code tries
to access this bucket:  an empty bucket has NULL
pointers where the vectors of keys and values should be,
and accessing code tries to dereference the NULL pointers.

I don't know that this error has been seen in real life.
It was provoked by a randomized multithreaded simulation
program that was trying to provoke errors.  This error was
provoked frequently by that program; no other kinds of
errors have come out of it.

Fix likely bug where calling tpc_abort() after a client disconnected
did not properly clear the client's internal state about the
transaction.  The change means that tpc_abort() will never raise a
ClientDisconnected error, even when disconnected.

Added a new test that sort-of covers this case and deleted another
that was testing, in part, that you did get a ClientDisconnected
error.

run from Daemon.

Zope3/ZODB4.  Many test fixes from Jeremy (in particular,
most of the tests weren't getting run), and new tests from
Tim.  Note that the new testEmptyBucketConflict() actually
shows that a particular rare case of conflict resolution
doesn't work correctly now.  A fix for that comes next,
along with reversing the sense of this new test.

repitition and no magical guessing of type names in the datatypes.

language.

- minor markup changes

component provided with zLOG.

- add at least something of a test for the datatype

Handing off to Barry.

ZEO.Exceptions.ClientDisconnected will always be raised when a client
is disconnected.  There's also a subclass of this exception in
ZEO.zrpc.error so that it's possible to distinguish whether the error
occurred in the RPC layer or at the storage layer.

If the client isn't connected at all, sync() returns quickly and the
test fails because it doesn't wait long enough for the client.

- convert hostnames to lower case

XXX Don't expect port 9 to do anything on any machine.

is check.check(btree), which performs value-based sanity checks on a
BTree (or TreeSet) that the btree._check() method doesn't do.  The new
checks include that all the bucket keys are in sorted order, and that
all the keys within each bucket, and within each internal BTree node,
lie within the range necessary for that node.  That last is a subtle
invariant that can't be checked locally:  it requires propagating range
info down the tree, and modifying it for each child and each level.
This *should* catch any BTree B for which iterating over the keys yields
a key K for which B.has_key(K) returns false.

Another function check.display(btree) prints the internal structure of
a BTree (or TreeSet, Bucket, or Set) to stdout.  If check.check(B) ever
complains, a clearer picture of the damage can be gotten by staring at
check.display(B)'s output.

Also beefed up the regular BTree tests by calling check.check() in key
places.  No surprises (the tests still pass).

XXX Maybe there should be an option to allow this.

A ZEO client can run in disconnected mode, using data from
its cache, or in connected mode.  Several instance variables
are related to whether the client is connected.

_server: All method calls are invoked through the server
   stub.  When not connect, set to disconnected_stub an
   object that raises ClientDisconnected errors.

_ready: A threading Event that is set only if _server
   is set to a real stub.

_connection: The current zrpc connection or None.

_connection is set as soon as a connection is established,
but _server is set only after cache verification has finished
and clients can safely use the server.  _pending_server holds
a server stub while it is being verified.

Before this change, a client could start using a connection before
verification finished.  If verification took a long time, it could
even commit a new transaction using a mixing of old and new data.

Pending does reads and writes.  In the case of server startup, we may
need to write out zeoVerify() messages.  Always check for read status,
but don't check for write status only there is output to do.  Only
continue in this loop as long as there is data to read.

test.

with StorageTypes.

conversion.

updated, which resulted in one whole cache being kept for no reason.

2 so they aren't normally run.