Made unpickler show the data from a pickled instance when it can't load the object from the ZODB for whatever reason.  Helps when trying to debug why your object won't load.

This reduced the amount of code and should
make the next step, adding failure handling,
much easier.

Also changed invalidation protocol to be atomic
(or close enough).

skip oid DECREFing logic.

parent is killed first.  (Otherwise, sometimes - often - a new child
was being spawned before the parent was clobbered, and the zeo server
survived...)

called TimeStamp_yad inconsistently.  Now both TimeStamp_abst and
TimeStamp_yad are called with "0-based" non-adjusted years.

management of pool lock.

were not handled correctly.

fsync when commiting transactions to make sure that transaction
data are written to physical storage immediately. There is circumstantial
evidence that database corruption has been caused due to problems with
delayed write of data after Zope has flushed transaction data.

Added logic to avoid writing empty transactions. It's imaginable that
some future application might want to write empty transactions to
capture transaction meta data. If this ever becomes an issue, then
this feature would have to be made optional.

Added utility code to recover corrupted databases. Note that
the recover method is imperfect. It doesn't recover lost data. It
just repairs the file so the lost data doesn't prevent startup.

To run the recovery code:

  - cd lib/python
  - python ZODB/fsrecover.py ../../var/Data.fs

  - Restart or pack Zope, causing an index to get written

  - Undo some transactions

  - Shutdown Zope ungracefully (e.g. kill)

When Zope comes up, the index points to undone records for some
objects. This can lead to all sorts of problems. :(

To overcome this problem, we now remove the index after an
undo.

This increases the likelyhood that it will take longer to restart
next time, but reduces the chance of a bad index.

Renamed some classes to make their intent clearer.

Fixed a silly typo in zrpc.

traceback info rectified by the last, more substantive checkin...

object that has previous records.  This caused a panic on startup
because the previous record pointer did not agree with the system's
knowledge that there was, indeed, a previous record. This is a
pretty benign situation, so, I've changed the check to log a warning
of the previous record pointer is zero and there is a previous record.

instances as non-persistent.