add Reconnector.reset()

[Brian Warner]

It would be handy if the Reconnector instances offered a 'reset()' method. This method should:

• lower self._delay down to self.initialDelay
• accelerate the expiration of any timer currently running (by doing self._timer.reset(1.0)

The use case is a Foolscap-using client on a laptop, which gets suspended, then resumed on an airplane without network connectivity for a while, then suspended again, then resumed with a real network connection. The goal is to accelerate the resumption of connectivity once the client is back on the net.

When the client wakes up the first time (on the plane), the banana-level keepalive timer will fire right away (since a long time has passed since it saw any traffic), which will cause the connection to be dropped. This will trigger the Reconnector to reconnect, but since there's no network on the plane, it will soon ratchet up to the maximum retry delay (one hour). When the laptop gets suspended again, it will somewhere in the middle of this one hour cycle.

Then, when it gets resumed again, the Reconnector's one-hour timer will fire immediately, probably before DHCP has had a chance to establish a new network configuration, which means the connection attempt will fail, and the Reconnector will schedule the next connection for an hour later.

An application which discovers the suspend/resume cycle (perhaps by scheduling one-minute timers and noticing when they expire much later than expected, or by some operating-system-specific means like D-BUS or COM or something) can poke all the Reconnectors that it's using by calling their reset() methods. It can do this as soon as it discovers the time-jump, which will trigger an immediate reconnect attempt (which will probably fail) and then try again using the normal exponential-backoff behavior, resulting in a new connection perhaps 10-60 seconds after the laptop is resumed.

Alternately, the application can pay close attention to the network configuration (again using some OS-specific mechanism) and refrain from calling .reset() until the network is back up. With this approach, the Foolscap connection should be successfully established immediately after reset() is called.

[Brian Warner]

It would also be nice to be able to ask the Reconnector for the last failure it encountered.. I can see this being useful in a client application, to populate the box that explains what's up with the current server connection. In addition, it'd be nice to provide application access to the delay until the next connection attempt.

[Brian Warner]

Done, in [f9aae96020d956363b3c4b2ff3006fba04b85fb7], including getDelayUntilNextAttempt and getLastFailure