The Python fatal errors occur only in a debug build now.

In a release build, unghostify() raises a Python SystemError
exception if it detects insanity, and ghostify() ignores the
problem (as ZODB 3.2 did, although it looks like 3.2 ignored
the problem by mistake).  This isn't *good*, because the
system is insane.  But it can become insane only by breaking
absolute threading rules, and that "should never happen".
Unfortunately, hundreds of things can go wrong if it does
happen, and we can't detect most of them.

In ghostify() and unghostify(), trigger a fatal error if the
object is insane.  This prevents a segfault (or, worse, arbitrary
memory corruption) later.

The test suite isn't bothered by this, and neither is bringing
up a Zope and playing around with it.  The only known cause
appears to be threading problems related to Transience.py,
partly explained in issue #1350.  It should be impossible for
these fatal errors to trigger via thread-correct use of ZODB.

I don't expect to keep these fatal errors in the code; indeed,
I'm checking this in only in Zope's *copy* of ZODB.  The intent
is to help whoever can make time for 1350 know whether that
problem still exists, until that problem goes away.  Unfortunately,
it's not even possible to raise an exception from ghostify()
(it's a void routine that "can't fail"), so it takes an extreme
measure to catch the problem as soon as it's visible.

Changing to pickle protocol 2 has severe backward compatibility
implications; changes to ZODB should not be made from the Zope
trunk regardless.

FileStorage.history() was reading the user, description,
and extension fields out of the object pickle, due to
starting the read at a wrong location.

store history informations. In ZODB 2.8 'tid' is used.
At least the management screen is showing up again however
the 'description' value shows only garbage. Also there might a 
problem with backward compatibility.

     - Re-added the DAV header (Collector #1518) which had been removed
       in beta 1.

Restored the ._opened attribute of Connection.  Don't know why it went away
in 3.3.  Probably because it was only referenced by connectionDebugInfo(),
and Jeremy didn't realize anyone used that <wink>.

The DB.cacheStatistics() method was introduced in DB.py rev 1.2,
and has always returned an empty tuple.  A number of "never did
anything, probably never will" DB methods like that were removed
in ZODB 3.3, to reduce stumbling over decoys.  That was discussed
on zodb-dev at the time, with universal agreement to get rid of
them.

So the resolution in this case is changing Zope to stop trying
to access the no-longer-extant cacheStatistics() method.  If
someone doesn't like this, they can revert this patch, then
change App/CacheManager.py's cacheStatistics() to return a
hard coded empty tuple <wink>.

Caution:  Since no deprecation warnings about Transaction.begin()
were raised by the test suite before this patch, none of this code
is exercised by the test suite -- or it is, but "something"
suppresses the deprecation warnings.  So it's hard to claim that
this patch has been tested; the strongest claim I can make is that
all the unit tests still pass.

1. a_Transaction_object.begin() is deprecated.  Don't use it.

2. Commit failure is "sticky" now:  the current transaction
   must be explicitly discarded (abort() or begin()) before
   a commit can succeed again.

Collector #1457: ZCTextIndex's QueryError and ParseError are now available for import from untrusted code.

     - Collector #1491: talgettext.py did not create a proper header
       for the generated .pot file if multiple pagetemplate files
       were processed.

- Updated to use transaction.commit() rather than
  get_transaction().commit()

       same signature as str.strip()

No commit message

dd Michael Dunstan's "explicit abort after error propagates into publisher" patch as documented in http://zope.org/Collectors/Zope/789 and as required by recent changes to ZODB which prevent a connection from being cleanly closed if modifications are extant in that connection.

(Merge from 2.7 branch)