(Merged from 3.7 branch.)

These are the ZODB part of the patches I posted to
http://www.zope.org/Collectors/Zope3-dev/655 with an additional import cleanup.
The issue was silent for over 2 weeks.

Also my attempts at subscribing to zodb-dev or sending a message there
dissapeared were doomed;)

I'm fully willing to revert this if someone has an issue with it.

    ------------------------------------------------------------------------
    r70059 | jinty | 2006-09-08 16:26:44 +0200 (Fri, 08 Sep 2006) | 1 line

    Forgot the NEWS entry. Hope I did it right.
    ------------------------------------------------------------------------
    r70053 | jinty | 2006-09-08 14:43:26 +0200 (Fri, 08 Sep 2006) | 1 line

    Clean up wierd import dance with ZODB. This is unnecessary since the transaction module stopped being imported in ZODB/__init__.py in rev 39622.
    ------------------------------------------------------------------------
    r70051 | jinty | 2006-09-08 13:24:45 +0200 (Fri, 08 Sep 2006) | 1 line

    Add the ability to ask a transaction if it has been doomed i.e. isDoomed().
    ------------------------------------------------------------------------
    r70050 | jinty | 2006-09-08 13:13:06 +0200 (Fri, 08 Sep 2006) | 1 line

    Add the doom() function to transactions. Look at tests/doom.txt for more info.
    ------------------------------------------------------------------------

problem reported on zodb-dev:

http://mail.zope.org/pipermail/zodb-dev/2006-August/010343.html

Added a new invalidateCache protocol for DBs and Connections to
invalidate the entire in-memory caches.  This is used when ZEO clients
reconnect.

test for it.

explicitly flush output to make sure we see test results.

ClientStorage could be in either "sync" mode or "async" mode.  Now
there is just "async" mode.  There is now a dedicicated asyncore main
loop dedicated to ZEO clients.

This addresses a test failure on Mac OS X,
http://www.zope.org/Collectors/Zope3-dev/650, that I believe was due
to a bug in sync mode. Some asyncore-based code was being called from
multiple threads that didn't expect to be.

Converting to always-async mode revealed some bugs that weren't caught
before because the tests ran in sync mode.  These problems could
explain some problems we've seen at times with clients taking a long
time to reconnect after a disconnect.

Added a partial heart beat to try to detect lost connections that
aren't otherwise caught,
http://mail.zope.org/pipermail/zodb-dev/2005-June/008951.html, by
perioidically writing to all connections during periods of inactivity.

port that nothing's listening on.

o Most notably, ZEO.ClientStorage (http://www.zope.org/Collectors/Zope/2016).

o Forward-ported from 3.4 branch.

I'm not particularly proud of the tests I wrote.  It's way to hard to
write tests for ZEO.  Without a lot of white-box trickery, nothing can
be tested without making network connections, which is insane. ZEO's 
architecture needs to change.

I finally had to resort to os._exit, which I'm not happy about,
although I don't suppose it could do any harm for the test runner.

I wonder is a test is leaving something behind it shouldn't.

Also return the test result status as the exit status.

PersistentMapping was inadvertently pickling volatile attributes (http://www.zope.org/Collectors/Zope/2052).

See http://www.zope.org/Collectors/Zope/2027.

replaced `x` with repr(x), and replaced apply(x, y) with x(*y)

For multiple undo to succeed, the undo operations have to be
performed in a specific order.  The order was not being retained
by ZODB and was instead semi-random (the order depended on the
id() function.)  Now undo operations (as well as all
ResourceManagers) are sorted by creation order.

in the second iteration

ZODB uses `buildsupport` now, not `zpkgsetup`.
Updating this info in PACKAGE.cfg is needed to
build a release tarball.

_ConnectionPool._reduce_size():  when forgetting a Connection
due to exceeding pool_size available connections, clear its
cache right away.  Because such a connection can never be in
the open state again, hanging on to resources in its cache is
just wasteful.  This was reported as "a problem" on zodb-dev
recently, although it's unclear how the poster got into a state
where it mattered so much.

New zdaemon.

_setstate():  An MVCC optimization was inadvertently disabled by
fixes for ZClasses.  Repaired.

Elsewhere, repaired English in comments.

NEWS.txt:  removed news from 3.6 and earlier.

Dmitry seems to have vanished :-(

Note that nailing the type of oid to str may allow some
thread simplifications in Connection._invalidated handling.
Thanks to Florent Guillaume for noticing!

  tools need to perform minimal logging configuration themselves. Changed
  the zeoup script to do so and thus enable it to emit error messages.

http://mail.zope.org/pipermail/zodb-dev/2005-March/008593.html