invalidation messages are recived after the cache is closed.

Changed connections to work with unset (None) clients.  Messages
aren't forwarded until the client is set.  This is to prevent sending
spurious invalidation messages until a client is ready to recieve them.

clients, but ZEO clients haven't provided very good protection,
leading to cache corruption.  We'll hopefully fix these client issues,
which cause other problems beside cache corruption, but it seems
prudent to provide low-level cache protection.

should close the old connection, and mark ourselves dissconnected --
or so it seems. :)  I'm chasing connection-invalidation bugs and this
rearrangement makes the logic seem a bit simpler to me and sets the
stage for a later fix for the invalidation problems.

read_only. It was set when a connection was tested, before the
connection was attached t the storage.  This made me wonder if the
flag and connection could get out of sync.  Because of details of the
complex connection dance, it appears that the flag will have a usable
value, almost by accident.  Ironically, if the storage was opened
read-only, this flag was set to true.  This all seemed very fragile,
and probably a bug magnet.  I refactored this so the flag is on the
connection, rather than the storage.  I also arranged that if the
storage is opened read-only, the flag is True.

of intermittent test failures.  In ConnectionTests, a random port was
selected without checking if it was in use.  testZEO.get_port (moved
to forker) picked a random port, checking if it was in use, but
clients actually used that port *and* the following one.  Now check
that the returned and subsequent ports are free. (Of course, they
could get used betweed the time they're selected and the time they are
used by the test. Oh well.

avoid spurious errors on exit, especially for scripts, such as zeopack.

effective. :)

references across databases when the referenced database has an empty
name.

was astronomical.  Also greatly simplified the code.

refactoring to simplify the data structures to fix a serious memory
bug: the cache uses waaaay the heck too much.

object will properly switch to longs when over/underflowing 32-bit values

- Cache records are written in several stems.  If a process exits
    after writing begins and before it is finishes, the cache will be
    corrupt on restart.  The way records are writted was changed to
    make cache record updates atomic.

- There was no lock file to prevent opening a cache multiple times
    at once, which would lead to corruption.  Persistent caches now
    use lock files, in the same way that file storages do.

- A bug in the cache-opening logic led to cache failure in the
    unlikely event that a cache has no free blocks.

When using ZEO Client Storages, Errors occured when trying to store
objects too big to fit in the ZEO cache file.

(backport from trunk)

(backport from trunk)