If SpendingController develops some internal state it should really remain
internal, anyway.  Don't make _plugin.py worry about this.

just bumping CI really

removing the operation-id may not actually be an improvement ... it is a
simplification, though.  However it requires us to load all the rows into
python and then send them back to the database instead of only loading them.
I thought removing the operation-id from the in-use table would be a win and
maybe it is but not for the reason I thought - sqlite3 emits the same code
whether you do `in [foo]` or `in (select x from [foo])` as far as I can tell.

Still, I like the simplification so we'll go with it for now.

Instead of immediately extracting passes, get them and later mark up the store
with the outcome of the attempt to use them.

Parens can create a tuple or something and we don't want that.

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