I supposes

and fix the implementation to read the configuration correctly!  thanks, test.

This test is bogus, though, because the Tahoe-LAFS web API test double
misbehaves for directory entry requests.

The capability encoding misbehavior breaks some of our unit tests which are,
supposedly, using the API correctly.

Encourage Hypothesis to explore a larger range for NotEnoughTokens

This should reduce the number of spurious changed-coverage reports.

hooray, more than a one-off fix

Use trial multiprocess feature even when collecting coverage

encourage Tahoe-LAFS nodes launched in the test suite to exit eventually

Previously we had it searching [1, inf] to discover the boundary at 2 ** 63.
Now we bias its distribution exponentially and hopefully find the very large
boundary sooner.

Also, remove a data() usage as long as I'm here.

Add automatic retries for some Tahoe-LAFS upload errors

If there are not enough reachable storage servers, try again.  Usually the
client node will manage to connect to some more eventually.

Include linting tools in test requirements.

Add some recovery-related endpoints

this will come in handy for building strategies for testing SQL interactions

Fix bugs in a client resource test which caused spurious fails and successes

Add Tahoe-LAFS `upload` and `download` helpers

Before it just ended up with DeferredResource which proves nothing at all.
Now it requires a sufficiently non-error-y status code to be happy.