FormatDriver conformance tests

[prdoyle]

We ought to have isolated tests for the FormatDriver implementations. Currently, they are tested only in the context of MainDriver, which has the risk of handling and recovering from errors caused by bugs.

Despite implementing the MongoDriver interface, they don't actually obey the entire contract, because they don't implement initialRoot or refurbish, instead implementing loadAllState and initializeCollection. That means they can't serve as the actual driver of a Bosk as-is. It's conceivable they could be tested without a Bosk object, but that's probably not realistic.

We probably need a simpler wrapper to stand in for MainDriver but without all the fault tolerance logic. Then, the FormatDriver conformance tests could be a superset of DriverConformanceTest plus some additional tests as appropriate.

[prdoyle]

It seems like the "simpler wrapper" will actually do quite a bit of what MainDriver does.

I'm realizing that MainDriver has two responsibilities:

1. Wrap a FormatDriver to adapt it to the contract of BoskDriver
2. Fault tolerance and recovery

For testing FormatDriver implementations, we want the first but not the second.

Logic I've identified so far that would fall under the "wrapping" category:

• Connecting to the database
• Creating a BsonPlugin and FlushLock
• Implementing initialState and refurbish in terms of loadAllState, initializeCollection, and onRevisionToSkip
• Creating a TransactionalCollection wrapper
• Calling commitTransactionIfAny after any driver operation that completes without throwing
• Polyfills
• MDC for logging
• Possibly eventDelayMS?

Logic that's not required for unit-testing FormatDriver:

• Format detection
• Dynamically changing FormatDrivers
• Retries

Requires more thought:

• ChangeReceiver? Do we still need a background thread and a ChangeListener? Could the harness just process all change events when flush() is called, a bit like BufferingDriver does?