Unittests modify DB concurrently

Many of our unittests test interact with the database. We use a real DB rather than a mock one, because the specific DB calls are important. When a test is done, we clean up its DB modifications by truncating each table.

However, this means we can't run unittests in parallel, since there will be spurious failures. There are a few approaches to this. For instance, Rails runs each test case inside a transaction that gets reverted when the test case is done. This, unless the test case itself tries to open a transaction. Transactions inside the test cases are a problem because MySQL does not support nested transactions. However, this may be sufficient for most of our test cases.

If we want to pursue the transaction-per-test-case approach, we probably need to modify Gorp to make DbMap's and Transactions interchangeable (or create an interface that both satisfy).

Start by reviewing the unit-test database cleanup flow and Gorp’s DbMap and Transactions APIs. Assess whether transaction-per-test-case isolation can support tests that open transactions themselves; done means unit tests can run in parallel without spurious database failures.