frontend: immutable check/verify/repair doesn't need the decryption key

[zooko]

For immutable files, Check/Verify/Repair? could do its work with only a verify cap, but currently the WAPI and the CLI seem to require a read cap. To fix this, relax the requirements of those front-ends so that they can make do with only a verify cap.

[warner]

I think that immutable check/verify/repair can work with only a verifycap, and that the internal classes (immutable.checker.Checker, immutable.repairer.Repairer) use verifycaps. The limitation is that the immutable FileNode class is the only way to get at the check() method, and it must be constructed with a readcap.

My thought is to create a new VerifierNode class, constructed with a verifycap. This class will provide the ICheckable interface, which is the one that contains the check() method.

The mutable checker/verifier should be able to work from a verifycap, so I'm thinking we can use the same technique (MutableVerifierNode.check). Mutable repair, however, requires a writecap, to generate the correct write-enabler on the new shares (so that writers can modify the new shares in the future). So MutableVerifierNode.check(repair=True) must be disallowed. One of the goals for DSA-based mutable files is to fix this limitation.

[zooko]

Let's release allmydata-tahoe-1.3.0 before fixing this ticket.