connection: disrupt the backoff timer on every retry
connection: disrupt the backoff timer on every retry

If an RPC is in flight when a TCP connection goes down, it gets an EIO
error.  If the RPC handler's `ShouldRetry()` method doesn't return
true for an EIO, it gets retried by the RPC connection itself.  But
it'll just loop back up into `waitForConnection()`, and the service
might have chosen a very long backoff timer to re-establish the
connection (in an effort to prevent thundering herds).

New RPC calls can override this by causing the random backoff timer to
fire immediately, but in-flight RPCs didn't do that on retries.

Until now.

Issue: KBFS-3404

keybase/go-framed-msgpack-rpc