Multi-threaded IO support, which is new to ZODB 3.10, allows clients to read
data (load & loadBefore) even after tpc_vote has started to write a new
transaction to disk. This is done by using different 'file' objects.

Issues start when a transaction is rolled back after data has been appended
(using the writing file object). Truncating is not enough because the FilePool
may have been used concurrently to read the end of the last transaction:
file objects have their own read buffers which, in this case, may also contain
the beginning of the aborted transaction.

So a solution is to invalidate read buffers whenever they may contain wrong
data. This patch does it on truncation, which happens rarely enough to not
affect performance.

We discovered this bug in the following conditions:
- ZODB splitted in several FileStorage
- many conflicts in the first committed DB, but always resolved
- unresolved conflict in another DB
If the transaction is replayed with success (no more conflict in the other DB),
a subsequent load of the object that could be resolved in the first DB may, for
example, return a wrong serial (tid of the aborted transaction) if the layout
of the committed transaction matches that of the aborted one.

The bug usually manifests with POSKeyError & CorruptedDataError exceptions in
ZEO logs, for example while trying to resolve a conflict (and restarting the
transaction does not help, causing Site Errors in Zope). But theorically,
this could also cause silent corruption or unpickling errors at client side.

(cherry picked from commit 028b1922)

Conflicts:
	src/ZODB/FileStorage/FileStorage.py

Fixing uncaught exception problem on shutdown

Nested connections try to clean up themselves multiple
times. This does not work

see https://github.com/zopefoundation/ZODB/issues/16

see https://github.com/zopefoundation/ZODB/issues/16

when objects had been added in readCurrent

still need to come up with a test

string representation.

https://bugs.launchpad.net/zodb/+bug/993350

  Conflict resolution failed when state included cross-database
  persistent references with classes that couldn't be imported.

the fix fix.

  Conflict resolution failed when state included persistent references
  with classes that couldn't be imported.

"Blob temp file get's removed before it should",
https://bugs.launchpad.net/zodb/+bug/595378

A way this to happen is that a transaction is aborted after the
commit process has started. I don't know how this would happen in
the wild.

In 3.10.3, the ZEO tpc_abort call to the server is changed to be
synchronous, which should address this case. Maybe there's another
case.

----------

- "activity monitor not updated for subconnections when connection
  returned to pool"

https://bugs.launchpad.net/zodb/+bug/737198