This condition can never succeed.

If the voucher is being seen for the first time at this point then it should
start redemption and the check will not pass.

If the voucher has been seen before and was in an error state to begin with
then the check higher up, outside of the loop, prevents execution from ever
entering the loop.

If the voucher has been seen before and just now entered an error state then
the `if not succeeded` check below, on the previous iteration, would stop the
loop and prevent this condition from ever being checked.

They're not primarily about super-largeness and super-large files prevent them
from working on Windows.

No one is going to run a storage server on Windows anyway

Compute it ourselves so it is correct for large files

This makes the test a little more challenging by adding some more bookkeeping
overhead that needs to be accounted for.

This removes almost all uses of the global value.  All that remains is its use
as a default in case no configuration is given.

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.