This way, it can be an empty list.

The first time the node starts there will be no rootcap and there cannot
easily be one unless the node is allowed to start so one can be created.

And a corresponding `created` field to the voucher model object which
propagates to the web view.

We do so by introducing a limitation that the client must be configured with
an issuer and it must match the issuer announced by any storage server the
client is to talk to.

The client will decline to speak to any storage server without a matching
issuer.

Although ... the client resource doesn't really the part of the redeemer that
needs the announcement.  Maybe that part of the redeemer belongs somewhere
else.  Probably.

lots of mess to clean up though

Passes cannot be constructed until we know how we're going to use them since
they are derived from the unblinded tokens and an operation-specific message.

Instead of never getting any passes, immediately get a pile of bogus passes!