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.

Switch to newer python-challenge-bypass-ristretto repo

And various associated changes necessary to keep the build working

Fix "cannot start a transaction within a transaction" during concurrent redemption

Still not testing the web code path but ... types and stuff!@

Connections could probably be in a per-thread cache or something but
redemption costs are going to dwarf database opening costs.

Also, filesystem caches and no benchmarks and all that.

A separate connection per concurrent transaction is required.

Support an increase in the ZKAP batch size to several hundred thousand

Configurable stripe endpoint

They have weird names in the Stripe API but there's no reason to preserve
that.

Tiny typo fix in the CircleCI configuration

CORS headers on Stripe charge API responses (even errors)

Also more consistent, correct error reporting from the HTTP API.
Also, better Stripe/database consistency in the case of errors.
Also, remove the unused Stripe webhook endpoint.
Also, some automated tests for some of this.

transaction rollback logic relied on exceptions, stripe charge function
signaled failure with Either, thus stripe failues had no effect on transaction
rollback

`catch` is not a good way to assert something is thrown