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.

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

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.

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.

caused an unneeded trigger to be created for each client
connection. This caused tests hang due to running out of file handles.

Let all server connections share a single trigger to avoid using too
many file handles in the server.

Fixed setup.py use of setuptools vs distutils, so .c and .h files are included in the bdist_egg. Merged from r90444 in the 3.8 branch.

- Fixed bug in bushy layout: oid recognition pattern would not handle hex
  representations correctly
- Fixed bug in lawn layout: empty strings (the base directory) would be
  recognized as the oid 0.

compatibility for the old `lawn` layout.

Notes:
 I had to exclude 'kill_does_not_cause_cache_corruption (ZEO.tests.test_cache.__test__)' from the test as it deterministically hung on my platform (with or without my fix)
 Running the remaining test suite caused Ran 3279 tests with 5 failures and 0 errors in 17 minutes 31.116 seconds and one import problem -- all failures and problems in zope.testing-3.5.1-py2.4.egg, i.e. unrelated to my fix:
Tests with failures:
   /home/dieter/ZopeSVN/W/ZODB/eggs/zope.testing-3.5.1-py2.4.egg/zope/testing/testrunner-coverage.txt
   /home/dieter/ZopeSVN/W/ZODB/eggs/zope.testing-3.5.1-py2.4.egg/zope/testing/testrunner-debugging.txt
   /home/dieter/ZopeSVN/W/ZODB/eggs/zope.testing-3.5.1-py2.4.egg/zope/testing/testrunner-edge-cases.txt
   /home/dieter/ZopeSVN/W/ZODB/eggs/zope.testing-3.5.1-py2.4.egg/zope/testing/testrunner-layers-ntd.txt
   /home/dieter/ZopeSVN/W/ZODB/eggs/zope.testing-3.5.1-py2.4.egg/zope/testing/testrunner-colors.txt

Test-modules with import problems:
  zope.testing.testrunner.tests

weren't constructed properly.

- The cache used an excessive amount of memory, causing applications
  with large caches to exhaust available memory.

- Fixed a number of bugs in the handling of persistent ZEO caches:

- Cache records are written in several steps.  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.

there are no tests for BTrees.Length; add tests that show that the Length
object will properly switch to longs when over/underflowing 32-bit values

instead of a POSKeyError.

Complete authentication configuration through XML on the client side. Server part was implemented way back in 2003.

mode.