It was passing but only after ~57 seconds because the busy_timeout setting in
the test definition was being applied to a different connection than was being
used by the implementation.

With this change we hook into the connection function and apply the shorter
busy_timeout after the normal setup work is done but before handing the
connection off to application code.

Have fewer SQLite3 "busy" errors

Handle exceptions during SQLite3 schema initialization and close the connection if necessary

Speed up the blinded token fingerprinting function

It seems to be faster to hash one huge string than many smaller ones that
total to the same length.  Also by only showing one final hash we remove O(N)
show calls.

The old and new fingerprints are not compatible but I haven't deployed this
in production anywhere yet so that doesn't bother me.  Had I, we'd need some
kind of versioning scheme for fingerprint computation I suppose.

Delay redemption response if it would be a "not paid" error

Internally try repeatedly to try to be able to return a success response.

I should really learn how to do some real logging...

Fix intermittent "Database is locked" errors

The default busy timeout is 0 and in the default configuration
read-blocks-write.  Thus by default it is extremely easy for concurrent
requests to the server to block each other.  So easy I can reproduce it with
about 100% fidelity in trivial local testing.

The transactions are all short lived, though, so re-attempting the lock
acquisition for for up to a second dramatically reduces the failure rate.

On a busy enough server it's conceivable a request might have to wait a full
second behind other requests to get access to the database.  In this case the
request will fail with the same "database is locked" error.  When that time
comes, it is probably worth just provisioning a faster server.  Or we could
explore WAL mode where read *doesn't* block write (though you can still only
have one writer and our API is pretty write heavy).

It's probably not strictly necessary but it's sort of nice.

Some minor cleanups, mostly docs/comments

The backend logic to make different counter values distinct during redemption

Also a little more frontend to handle possible failure modes

Accept a counter value in redemption request

This is a step towards being able to scale up the number of tokens issued.