Along with an in-memory implementation of a pass factory that works with it.

`assertThat` and `succeeded` can do the job *most* of the time.

If all passes were good but there simply were not enough of them, don't retry.

Replace the tricky _rref property with a decorator.  This guarantees _get_rref
is evaluated for each function call before we do anything with pass generation.

Same logic should apply to the rest of the pass-spending methods.

Then, logic can be extended to cover retry for other failures and putting
passes back in the database for non-spending failures and converged uploads.

Meant this to be in PR#152 but somehow forgot to even commit it...

Also centralize the exception-raising in one place

And update tests to take advantage of free equality we get

The 2nd get_tokens is never used so the line it is defined on is considered
partially covered.  Replace the lambda with None and explain what's going on.

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.