Xud: Revoke connection retries

[moshababo]

When attempting to connect to an unreachable node, connection retries procedure might trigger, which will last a long time. During that time, it's not possible to connect to a different address of the same nodePubKey.

We should add support for cancelling the connection retries, perhaps by re-adding the disconnect cmd, which was removed, and apply it on the connection retries as well.

[kilrau]

How this happened (admitted, very special circumstances):

we set up 2 environments with 2 different xud's and 2 different nodePubKeys but which (for some reason) had the same IP. Connecting xud1 one to xud2 succeeded once. Then we noticed the IP issue, changed IP of xud 2 and tried connecting again. Not possible because xud threw an "Already exisitng connection attempt". Problem: "Already existing connection attempt checks only nodePubKey, but not not IP:Port.
Solution01: make connection attempt check the full URI, including IP & Port
Solution02: Implement a "disconnect" funtion which closes socket to peer, remove peer from nodes list

Actually Solution01 should be done anyways, easy to do and solve this problem. Opinions? @moshababo @sangaman @offerm

[moshababo]

Implementing Solution01 isn't straightforward - we structured many features on the premise having one-to-one relationship between a connection and a nodePubKey.
Also, it might not even solve the problem - the connection retries wouldn't trigger if "Already existing connection" error is thrown. They probably started when you weren't connected.

I'd suggest to go with Solution02 which sounds useful non-related to this issue, since the connection retries procedure is very long.

[sangaman]

How about when we manually try to connect to a given node pub key, we cancel any pending connections for that node pub key and then start the manual attempt. That should solve the problem, right? I think it would be easier/cleaner to implement.

[kilrau]

What would we do without @sangaman !? 👍

Sounds good to me and is a solution precisely targeting our scenario. What do you think? @moshababo From my side good to go.

[moshababo]

@sangaman i'd say that having implicit side effects is less optimal, but since it's just about cancelling the connection retries (and not an actual connection), it should be fine.