However, we still cannot be frozen (because of Failure.cleanFailure) and
cannot use attrs exception support (because we want value-based comparison).

They're all redundant on Python 3

Now PaymentController has a set of these as an attribute.  It could possibly
consider making some decisions based on this value now.

We're going to start looking at it.  It's not reasonable for its value to be None.

Otherwise idle tahoe processes consume enormous amounts of CPU time.

Fixes #177

it's unclear what a good testing strategy for this logging is.  should switch
to eliot soon.

So we'll just have a practical zero second delay

Combined with the new issuer behavior, this should not impose an
undue load on any part of the system while providing the most
responsive payment experience possible.

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.

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.

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