Because the error semantics of load and loadBefore differ enough that
changing calls isn't trivial.  Plus the helper serves as a handy
transitional load implementation.

Simplify MVCC by determining transaction start time using lastTransac…

Obviously the tests don't call this. This is probably because they use
DB.storage (rather than DB._mvcc_storage).

Conflicts:
	setup.py
	src/ZODB/tests/synchronizers.txt

Abstract ZODB's MVCC implementation into a storage adapter.

- Lower-weight instances when not using RelStorage

- Still works with new RelStorage instances.

- Doesn't make me include loadBefore in MVCCAdapterInstance objects. :)

Hopefully, this will make linters happier.

I'd started to edit it to remove implementation details and got
distracted, leaving it half edited.

This allows us to not worry about method overriding and avoids
creating wrapper methods (some of which were broken).

My guess is that performance is a wash.  We take a tiny hit on the
first access, because ``__getattr__``, but we don't have to copy
methods we never use.

It wasn't really needed or used and caused a stupid ZEO test failure.

I do think the storage API needs to be thought about and refined at
some point, but now, it's not a priority.

I'd lazily assumed that undo and tpc_vote has the same sorts of
returns, but they don't.  When tpc_vote isn't None (ZEO), the retrun
is a list of oid and serial pairs.

To prevent modifying the set of instances while iterating over them.

That's applied to storages other than RelStorage.

See: https://groups.google.com/forum/#!topic/zodb/QJYmvF0eUUM

Fix winbot failures

Thanks

This fixes the following random failure:

Failure in test checkBaseHistory (ZODB.tests.testDemoStorage.DemoStorageTests)
Traceback (most recent call last):
  File "unittest\case.py", line 384, in _executeTestPart
    function()
  File "ZODB\tests\testDemoStorage.py", line 96, in checkBaseHistory
    self._checkHistory(base_only())
  File "ZODB\tests\HistoryStorage.py", line 46, in _checkHistory
    self.assertLess(a, b)
  File "unittest\case.py", line 1026, in assertLess
    self.fail(self._formatMessage(msg, standardMsg))
  File "unittest\case.py", line 508, in fail
    raise self.failureException(msg)
AssertionError: 1465433823.260304 not less than 1465433823.260304

And in special case where a connectin is opened while a transaction is
active (Zope2).

It's too hard to remember to update the meta data (we've been in beta
for a long long time).

By resetting self.__onCloseCallbacks before calling the close
callbacks to forestall infinite recursion (as can be the case when a
close callback is the database close methos).

Changed it to the value corresponding to the maximim *signed*
big-endian 64-bit integer, because of LxBTrees.

Note that this value isn't used anywhere in ZODB yet.

Maybe it should be.

To mitigate errors during tearDown.

Lots of tests are sloppy about closing connection (because they could
be), but storages tend to get closed and transactions aborted. This
has the effedt of calling afterCompletion on connections which tries
to call storage lastTransaction, which causes errors.

Conflicts:
	CHANGES.rst

Cuz I neglected to push when I made 4.3.0. Thanks DCVS!