1. The saving was performed in (tpc)_finish.  It is important that this
   method do as little as possible because it cannot fail!

2. The algorithm for deciding how often to save was broken. For large
   databases, for which saving periodically is desireable, the period
   was set so high that the index was effectively never saved.

It might be nice to save periodically, but doing so is tricky, since
we really don't want to do it during commit.  Until we figure out how
to do this right, it is better not to try.

In the mean time, we save on close and on pack, which is proably often
enough in most cases.

Windows. :/

have not been initialized (as can happen when doing a deep copy of a
blob object)

a possible ordering problem for invalidation messages.

This was motivated by code inspecition during merge of an earlier
refactoring to the trunk.  The refactoring also simplifies the code
and probably makes it a tad faster.

  with the data in a way that prevents data from being loaded into the
  cache. We don't yet know why, but added an exception handler to
  prevent this error from being fatal.

written on.

for large databases on systems that don't allow many subdirectories.

an out-of-date server.

servers with zeo clients to be delayed.

  of a Python disctionary for a mapping that can grow large.

(Not large enough to use a lot of memory, but large enough to cause
  malloc to fail. :()

for objects that were explicitly added to a database if the object
was modified after a savepoint that added the object.

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.