athens: Ensure storage tests can run without intermittent failures

Storage tests right now run in parallel against the same shared datastore, so intermittent failures can happen due to race conditions (@marwan-at-work mentioned that he’s seen some).

We should think about whether we can do something to make this more “foolproof”. One idea is to use testify/suite’s SetupTest and TearDownTest functions to provide each test with its own database (or whatever is appropriate for the given storage driver)

Another option is to run with go test -p 1 ... to ensure all tests don’t run in parallel (this is what the buffalo CLI does). I don’t feel like that’s an ideal solution, but it works for them.

cc/ @michalpristas @robjloranger @marwan-at-work since we’ve all talked about testing in one way or another recently