This makes the database responsible for remembering how many tokens we expect
to get for a voucher, rather than the in-memory Python state or the code.

As a result, we can resume redemption knowing the correct number of tokens
after a process restart and without relying on the PaymentController's default
token count to have remained unchanged.

This makes the tests faster and avoids hypothesis complaints about assumptions
that fail too often.

Redeem the voucher once for each redemption group.
Track progress in the database.
Delay entering the "redeemed" state until all groups have succeeded.

This gives us more tokens than there are redemption groups, a requirement

They must use at least as many tokens as there are redemption groups

Previously the implementation allowed colliding passes if unblinded tokens
shared a prefix or suffix.

Allow voucher additions that are only distinct on the counter value.

Add counter to database and Python representation

A new voucher has not been redeemed any times.

Replace IRedeemer.redeem with a counter-accepting API and update callers

Add an interface for inserting tokens

Merge pull request #126 from PrivateStorageio/125.backup-order-equals-spend-order-equals-insert-order

Make backup order equal spend order equal insert order

We have our new test that verifies ordering