add error indicators to Reconnector

[Brian Warner]

For Tahoe, it'd be nice to let the user know *why* certain storage server connections could not be established. We recently added connection handlers, which makes it possible for a tahoe client to be configured to never connect over plain TCP (always routing such hints over Tor instead). If Tor is unavailable, some FURLs won't be connectable, and unlike normal server-not-responding errors, the corrective action is for the *local* user to install Tor.

For one-shot Tub.getReference() calls, we currently signal this with a NoLocationHintsError (although we should add some more details to the exception's text argument). But for Tub.connectTo(), there's no error indication: the callback is fired each time a connection is established, but nothing ever indicates an error, so there's no pathway to deliver the information that a functional connection-handler could not be found.

Unfortunately the *args and **kwargs of Tub.connectTo are already claimed (they are passed through to the callback function). So I think we'll need a new API method. I'm thinking that it should take both callback and errback arguments (each just a single callable, and obligate the user to write a lambda x: if they want additional arguments). Then the callback would be fired upon successful connection as before, but the new errback would be fired (with a Failure) each time the connection attempt failed.

Then Tahoe's server-status page could remember the message from the last time the errback was called, and display it on the status page until the callback() fires to replace it.

Then I think we should expand the set of exceptions a little bit, so there's enough information for Tahoe to e.g. realize that the FURL contained only a TCP hint but it'd been configured to ignore them.

[Brian Warner]

Ticket retargeted after milestone closed

[Brian Warner]

Oh, I forgot that tub.connectTo() returns a Reconnector object. We can just add an accessor: reconnector.getConnectionStatus(). That will return the same ConnectionStatus object as the #267 rref.getConnectionStatus(), with the same snapshot of attributes.

There's no async notification of attempted connections failing, but if the applications wants to learn the current status, it calls getConnectionStatus() and the object it gets back can reveal the state of the most recent attempt.

The Reconnector might want some additional properties: how long ago did we make the most recent attempt, and how long will it be until we try again.

[Brian Warner]

I wound up implementing this with reconnector.getReconnectionInfo(), which has attributes that describe the most recent connection attempt and its results. Most of this landed in [f104e1c01].