Fix testMinimizeTerminates

This test was spewing exceptions without failing for ZODB5.

The spew was an indication that something was wrong in this case. (The
test was broken.)

There had been some bug in the object cache that caused an infinite
loop when objects woke themselves up while being reaped.  This test is
a regression test for that bug.

The test was sloppy about transaction managers.  The test class
creates a bunch of connections using the threaded transaction manager,
but this test used a thread to execute the critical code.  As a
result, the synchronization methods weren't called.  This didn't
matter much with ZODB4.  The objects were still able to load their
state.

With ZODB5, the synchronization methods are important for proper MVCC
and because they weren't called, the objects' state couldn't be
reloaded, with 2 effects:

- Spew

- The test wasn't really testing that object's that reloaded
  themselves didn't create an infinite loop.

Changed the test to not use a threaded transaction manager.

As part of a project to provide object-level commit locks for ZEO, I'm
refactiring FileStorage to maintain transaction-specific data in
Tranaction.data.  This involved undo.  In trying to figure this out, I
found:

- A bug in _undoDataInfo, which I verified with some tests and

- _transactionalUndoRecord was maddeningly difficult to reason about
  (and thus change).

I was concerned less by the bug than my inability to know whether a
change to the code would be correct.

So I refactored the code, mainly transactionalUndoRecord, to make the
code easier to understand, fixing some logic errors (I'm pretty sure)
along the way.  This included lots of comments. (Comments are much
easier to compose when you're working out logic you didn't
understand.)

In addition to makeing the code cleaner, it allows undo to be handled
in cases that weren't handled before.

Per @jimfulton, handle_all_serials shouldn't be sniffing in ZODB5

Thanks.

Fix handle_all_serials for the new and old protocols.

Switch all storages to the new commit protocol

Thanks!

Only tpc_vote can report resolved conflicts with the new commit protocol

Merge 4.x branch

Better support of the new API to notify of resolved conflicts (store/tpc_finish)

Conflicts:
	src/ZODB/interfaces.py

ZEO handles undo asynchronously and ZODB has for some time allowed
undo oids to be returned via vote.

Conflicts:
	src/ZODB/interfaces.py

Define a new interface for storages that support the new commit protocol.

When switching all storages to the new API in the master branch,
I found a few issues, mainly with blobs.

1. Created/modified blobs are invalidated during the first phase
   (in Connection._store_objects):

    obj._p_invalidate()

    And with the old API, _handle_serial then sets _p_serial
    Ghost objects are not supposed to have a _p_serial and with the new API,
    a few tests would fail because _p_serial are checked without activating the
    blob first.

2. Another consequence of _handle_serial not updating _p_changed/_p_serial
   immediately is that created objects are stored twice if __getstate__
   modifies itself. This case is tested in testConnection by
   doctest_lp485456_setattr_in_setstate_doesnt_cause_multiple_stores

    Hence the change in Connection._commit:
    - self._modified is already appended in Connection._store_objects
    - (obj._p_serial == z64) instead of (oid in self._creating)
      would not work for savepoints.

3. Setting _p_changed of a Blob with no uncommitted changes would cause an error
   (lp440234_Setting__p_changed_of_a_Blob_w_no_uncomitted_changes_is_noop)

    Fixed by the same change as in 2:
    - oid was appended twice to self._modified but reverted one
      (self._modified.pop() in _store_objects)
    - the test passed because _p_changed was reset early by _handle_serial