backoff late connection failures

[rade]

If a connection gets through all the handshake and subsequent checks - i.e. it ends up getting added to the LocalPeer's connection list - but gets terminated within one minute (of the start of the successful connection attempt), then we apply the existing backoff logic to schedule a retry, instead of retrying immediately.

In order to do this we retain the 'Target' data structure for such connections, marking it as 'connected' instead of deleting it (as we did previously).

Fixes #953.

[rade]

Items for discussion:

• the ResetAfter interval, currently set to 1 minute, which determines how long a connection must stay alive for it to be retried immediately on subsequent failure instead of being subject to backoff. Note that this period starts at the time the successful connection attempt was scheduled for and hence includes a) any delays in CM to attempt the connection, b) the time it takes perform the handshake and other checks. We could exclude the latter two by adding a target.tryAfter = time.Now() to ConnectionMaker.ConnectionedCreated(), but this would "overshoot" in the other direction since any delay in CM processing the event would be excluded too.
• the three refactoring commits; they are in a dependency chain but I'd be happy to lop some off the end
• smoke test: I could add one, but it would involve some sleeps and poking the weave status, which is rather distasteful. Note that code coverage of the new code is already excellent, so is it worth for an extra three lines of coverage?

[rade]

an extra three lines of coverage?

Actually the behaviour we want to test for - that connections which fail shortly after establishment don't trigger an immediate reconnect - doesn't expand code coverage; the three uncovered lines are for the case that the connection failed later. And we probably don't want to wait that long, depending on what ResetAfter interval we settle on.

And even writing a test for the former is tricky; the difference in connection status is that previously we'd cycle through retrying, pending, established, whereas now it's failed, retying, pending, established. The duration of the failed state will be quite short to start with, and expand as the backoff kicks in. I cannot think of a simple way to write a test here that wouldn't be prone to all sorts of timing-related failures.