ZPublisher error path can aggravate error

[Vincent Pelletier]

Sample scenario:
 - undo a transaction which cannot be undone
   Effect: MultipleUndoErrors is raised in TPC
 - publisher catches the exception, and calls error hook if set
 - abort transaction
 - return result to the user

If error hook attemps to join the current transaction, it will get an exception since
the transaction already failed.

I suggest aborting the transaction immediately in the error path, and creating
a new one which will be aborted after the error gets rendered (using existing code).

[Dieter Maurer (d.maurer)]

The suggested behaviour was the one implemented in old Zope versions.
It has the disadvantage that the error handling does not see the state which caused the problem which
is especially nasty for session releated problems.

Instead, the ZODB should not prevent "join"s to a doomed transaction (only "commit"s)
as a "join" does not rely on the non doomedness. Preventing "join"s may only be justified
by arguing that finally the transaction must be aborted such that any work on it is waste.
However, this forget about the essential use case of error handling.

[LeoRochael (leorochael)]

The released 'transaction' module already implements the "join doomed transactions" as exemplified by tests/doom.txt