They're decompressed automatically to temporary files.

The use of ZODB.broken was completely wrong so previous code only worked
if NEO could import all classes used by the application.

RTMIN+1 & RTMIN+2 signals, which were previously used for debugging,
have been remapped to RTMIN+2 & RTMIN+3

No journal on disk anymore because this is incompatible with the
rename+reopen way to rotate logs, and we want to support logrotate.
Of course in case of crash the log may be corrupt or entries may be lost,
but we currenty don't think NEO logs would be useful to debug such failure.

This commit only moves code from setup() to _setup()

The only purpose of committing during import is to not restart from the
beginning in case of interruption.

If not implemented, this should not result in a fatal error that kills the
storage. Instead of that, a new error packet is sent so that the exception is
raised in the client.

That seems too verbose now but it was difficult to know the ports of nodes
when only warnings were output.

Of course, neoctl should only connect to the admin, but in case of user mistake
the queried node should not die. Ideally, all other commands should be checked.

It was broken since review of logging
(commit 1fce5cc4).

_getPartition optimization can't be done at class level and properties hide
instance attribute so implement laziness in __getattr__

This is not a valid place to call app.newTask

The following 3 methods are renamed:
 unlockData -> releaseData
 storeData -> holdData
 _storeData -> storeData

and StorageOperationHandler use the new storeData instead of the old one.

For the moment, this is only useful for debugging.

Transaction manager uses a new getLastObjectTID method instead of
getObjectHistory, because the latter fetches the data and this is
a waste of time here.

Similarly, minimize SQL work in getObject if the object can't be found.

Although it's a warning for developers, it's only informational for users
so lower severity in order not to frighten them.

- Fix case of empty values: there's no reason to do anything special for them.
- Do not warn about multiple level of indirection to get data serial.
  With the current structure of tables, this does not cause significant
  performance issue as it did before.

Export:
- Remove leftover warning about a bug that was fixed in
  commit e76af297
- In neomigrate script, open NEO storage read-only.
- IStorageIteration is already implemented.

Import:
- Review comments.
- In neomigrate script, warn that IStorageRestoreable is not implemented.
- Do not call 'close' method on source iterator. BaseStorage does not do it and
  this is not part of ZODB API. In the case of FileStorage, resource are freed
  automatically during garbage collection.

This is more realistic than testing with a single partition, in particular when
there are more storage nodes that copies.

There is simply no way to guess data serials and instead of producing random
values, the only solution is to retrieve the values from storages.

There are still differences for data serials between FileStorage and NEO:
- NEO always resolves to original serial, to avoid any indirection
  (which slightly speeds up undo at the expense of a more complex pack code)
- NEO does not make any difference between object deletion and creation undone
  (data serial always null in storage)
It has to be decided whether NEO implementation should be changed about this.

Apart from that, conversion database back from NEO should be fixed.
testExportFileStorageBug passes and there was in fact no FileStorage bug.

Another change is that iterator does not trash the client cache anymore.