It is observed for each redemption group and it could vary for groups
belonging to a single voucher.

Take care not to spend them, though.

It doesn't make the test much faster ... but maybe a little?  It does slightly
improve failures by producing fewer giant base64 strings.

This will make it easier to add the new allowed-public-keys item which must be
present regardless of chosen redeemer.

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.

This exercises whitespace and no-whitespace cases.

... on purpose so devs know what to expect from users like me.

It is easy to erroneously add extra white space to a text file. For example when writing with an editor like `nano` or when using `echo` without the `-n` argument.

Handing that white space over to python-challenge-bypass-ristretto's `decode_base64()` method will make it fail in a rather opaque way, see https://github.com/LeastAuthority/python-challenge-bypass-ristretto/issues/37.

This eliminates white space including newlines around the key expected to be in that file.

The redeemer will submit this many tokens with its redemption request now.  It
needs to agree with whatever the issuer wants to do, of course.

It builds _Configs instead of functions that return _Configs.

Also add a test that actually serializes it

The entire ZKAPAuthorizer client resource hierarchy is now protected by this
token, ensuring any callers at least have local filesystem access to the
Tahoe-LAFS node.

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