We can't control whether Stripe puts the voucher we supply in its metadata.
We can control whether we put the Stripe ChargeId Stripe supplies in our
database, though.

This lets me add a new charge_id column to the vouchers table.
This lets us associate vouchers with transactions on our side.
This provides redundancy with the association on the stripe side.
With this redundancy we can let metadata mismatches go by
(maybe with logging/alerting)
instead of making them fail the whole process.

The new stanza is the automatic result.

Do a better job generating sensible error results from the payment endpoint

Stripe CardError is now the only error to receive a "Stripe charge didn't
succeed" response.  Other Stripe errors can now fail in other ways.

This is a better client interface and makes HTTP status codes more accurately
reflect the failure which makes them more usable as a monitorable metric.

Add a metric for signatures issued

Record first successful redemption of any voucher, counter pair

So, let it.  Just demonstrate we at least see the test metric.

Add general HTTP metrics and particular Stripe charge metrics

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...