The HoserStoppage and ExceptionInTpcFinish were failing intermittently
on Windows.  I assume the problem is that a single error in tpc_finish()
can be recovered from iff the error is for the first jar.  I assume that
most of the time the error occurred after some other jar had committed.
Fixed the test by causing two different jars to fail.

XXX This makes CommitLockTests pass on Win2k for me.

tpc_abort() and tpc_finish() should always reset _transaction and
strategy attributes before calling _handle_waiting().  XXX Not sure
that it actually makes a difference, but the code seems simpler.

Only issues the "blocked transaction restarted" method when _restart()
returns true.

XXX If select() raises an exception inside asyncore, close the connection.

Use TestThread as base class for WorkerThread in CommitLockTests.

StorageTestBase.removefs() will attempt to remove files with all the
possible extensions that FileStorage will create.  It will raise
os.error for any error except ENOENT.

Remove many variants of removefs() implemented in the various test
suites.

Add a poll call in send_reply() so that synchronous calls made when
there is no other traffic don't cause long delays.  (This probably
only occurs during the pack tests.)

XXX This will probably hang for Guido.

Mark each WorkerThread as a daemon.  Attempt to join() it when the
test exits, but do so with a timeout.  If, after the join(), the
thread is still alive, mark the test as failed.  Since it's just a
daemon thread, the test program should still exit.

Also, reformat doc strings, remove an unused global variable, and
remove one whitespace character.  (I've already used the whitespace
in a different module.)

No log writer that I know of has a reinitialize() function.
zLOG has an initialize() function, but it isn't easy to get at yet.

Add a couple of simple tests that make sure that start.py script
runs.  The tests are meager -- most of the possible arguments are
untested -- and only run on Unix.

I think this is the log call that has been killing backends by sending
very large strings.

It's not a good idea to set this option.

Log message less choppy.

There was an info-level log call when a transaction was blocked, but
not a complementary one when the transaction was resumed.  Added the
latter, so that the log provides a clear record of whether the server
is wedged or working.

I was always uncomfortable with this, but its portability is a simple
justification for removing it.