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.

Because masters don't have persistent storage, the task to remember whether
the cluster is in backup mode or not is delegated to storages, via the presence
of a 'backup_tid' config value.

This fixes a bug that set 'backup_tid' after a simple replication.
If the cluster was restarted, it would have tried to switch to BACKINGUP state.

It would be unreliable to resume printing logs using a condition on date,
so the format of log files is changed to add primary keys that number records.

This should fix the following failure:

Traceback (most recent call last):
  File "bin/neostorage", line 23, in <module>
    neo.scripts.neostorage.main()
  File "neoppod/neo/scripts/neostorage.py", line 80, in main
    app.run()
  File "neoppod/neo/storage/app.py", line 167, in run
    logging.exception('Pre-mortem data:')
  File "/usr/lib/python2.6/logging/__init__.py", line 1088, in exception
    self.error(*((msg,) + args), **{'exc_info': 1})
  File "/usr/lib/python2.6/logging/__init__.py", line 1082, in error
    self._log(ERROR, msg, args, **kwargs)
  File "/usr/lib/python2.6/logging/__init__.py", line 1173, in _log
    self.handle(record)
  File "/usr/lib/python2.6/logging/__init__.py", line 1183, in handle
    self.callHandlers(record)
  File "neoppod/neo/lib/logger.py", line 210, in callHandlers
    self._queue(record)
  File "neoppod/neo/lib/logger.py", line 200, in _queue
    self._release()
  File "neoppod/neo/lib/logger.py", line 79, in _release
    self._async.pop()(self)
  File "neoppod/neo/lib/logger.py", line 96, in flush
    self.db.execute("BEGIN")
sqlite3.OperationalError: cannot start a transaction within a transaction

This is a follow up of commit 1f6bbcc1
("Rewrite (inside protocol, to make it standalone) a simpler Enum type"),
which renumbered values of CellStates enums.

In STOPPING state, the primary:
1. rejects all clients and any new node
2. finalize remaining transactions
   (i.e. those for which a tcp_finish was received)
3. finally shut down all nodes of the cluster

During election, nodes are not identified anymore.
testElectionWithManyMasters only worked thanks to the election timeout.

Also, change the way TTIDs are generated in preparation for that bug's fix:
we will need TTID to be monotonous across master restarts and TID generator
provides this feature.

This should never trigger, as gmtime bases itself on a unix epoch
timestamp which is non-monotonous on leap seconds. So gmtime cannot
return second count above 59.