Without this, transactions and even objects may be missing on the backup
database.

This fixes the following assertion failure:

PACKET #0x021d Ping                           > M1 (10.0.114.64:14001)
INFO   timeout for #0x0000021d with <ClientConnection(uuid=M1, address=10.0.114.64:14001, closed=0, handler=BackupHandler) at 2955590>
DEBUG  connection closed for <ClientConnection(uuid=M1, address=10.0.114.64:14001, closed=1, handler=BackupHandler) at 2955590>
ERROR  upstream master is down: connection lost
ERROR  Pre-mortem data:
ERROR  Traceback (most recent call last):
ERROR    File "neo/master/app.py", line 134, in run
ERROR      self._run()
ERROR    File "neo/master/app.py", line 154, in _run
ERROR      self.playPrimaryRole()
ERROR    File "neo/master/app.py", line 344, in playPrimaryRole
ERROR      self.backup_app.provideService()
ERROR    File "neo/master/backup_app.py", line 129, in provideService
ERROR      conn.close()
ERROR    File "neo/lib/connection.py", line 541, in close
ERROR      assert not self.isPending()
ERROR  AssertionError

SQL tables can be upgraded using:
  UPDATE config SET name = 'nid' WHERE name = 'uuid';

then for MySQL:
  ALTER TABLE pt CHANGE uuid nid INT NOT NULL;

or SQLite:
  ALTER TABLE pt RENAME TO old_pt;
  CREATE TABLE pt (rid INTEGER NOT NULL, nid INTEGER NOT NULL, state INTEGER NOT NULL, PRIMARY KEY (rid, nid));
  INSERT INTO pt SELECT * from old_pt;
  DROP TABLE old_pt;

- fix stopping backup cluster
- fix leaving backup mode, including truncating to consistent TID
- fix backup_tid on master and storages

And contrary to previous implementation, there is no automatic reallocation
of partition amongst remaining nodes. Now only 'tweak' does that.

This fixes a bug in backup mode where 'loid' was not updated.

This changes is similar to commit 3d0fab20
("logger: retry instead of raise if the log is locked by another process").

This changes completely how to get data from storages than is not too
recent and NEO now behaves as expected by ZODB, instead of trying to
snapshot at Storage level.
However, ZODB should probably be changed to avoid double loading when
an invalidation is received during a load.

This fixes the following an invalidation bug:

ERROR ZODB.Connection Couldn't load state for 0x504e
Traceback (most recent call last):
  File "ZODB/Connection.py", line 851, in setstate
    self._setstate(obj)
  File "ZODB/Connection.py", line 916, in _setstate
    self._load_before_or_conflict(obj)
  File "ZODB/Connection.py", line 931, in _load_before_or_conflict
    if not self._setstate_noncurrent(obj):
  File "ZODB/Connection.py", line 954, in _setstate_noncurrent
    assert end is not None
AssertionError

If any object is modified after the start of a transaction, the snapshot
TID of the NEOStorage is ignored because ZODB will use the TID of the first
received invalidation.

This fixes an invalidation bug, including the following critical error:

CRITICAL txn.140440071526144 A storage error occurred during the second phase of the two-phase commit.  Resources may be in an inconsistent state.
------
ERROR Zope.SiteErrorLog 1342544345.990.582646288246 /erp5/person_module/Folder_create
Traceback (innermost last):
  Module ZPublisher.Publish, line 137, in publish
  Module Zope2.App.startup, line 291, in commit
  Module transaction._manager, line 93, in commit
  Module transaction._transaction, line 322, in commit
  Module transaction._transaction, line 424, in _commitResources
  Module neo.client, line 42, in tpc_finish
  Module neo.client.Storage, line 135, in tpc_finish
  Module neo.client.app, line 773, in tpc_finish
  Module neo.client, line 36, in callback
  Module ZODB.DB, line 693, in invalidate
  Module ZODB.DB, line 532, in _connectionMap
  Module ZODB.DB, line 221, in map
  Module transaction.weakset, line 58, in map
  Module ZODB.DB, line 692, in inval
  Module ZODB.Connection, line 350, in invalidate
AssertionError: invalidations out of order, '\x03\x97\xec;\x19\x86\xc9\xf6' < '\x03\x97\xec;\x19\x87_\xdd'

In particular, a cluster may now starts automatically so 'simple' can't know
whether the cluster is in an expected state or not.