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.

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

It is stored on redemption and regurgitated by the Python APIs and dumped in
the JSON accessible via the HTTP API.