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.

A new voucher has not been redeemed any times.

We have our new test that verifies ordering

It was doing to do some complex time math and decide if the voucher redemption
looked legit but the whole premise is broken.

The only thing you might be able to decide about a key change on a new voucher
is that some *older* ZKAPs might be suspicious.  And, really, what you should
probably decide instead is that whole issuer is suspicious and you might need
to stop using it.  On top of that, you need more information than what you get
from voucher redemptions.  You need more frequent monitoring of the issuer's
key in case you don't redeem vouchers except once in a blue moon.

So hanging a suspiciousness on a voucher isn't coherent.

And API docs