Improve connectd to try non-tor connection first and filter duplicates

[m-schmoock]

This does:

• remove duplicate connection attempt if addr_hint was set and also added by gossip.
• try non-tor connections first as they are usually faster and more reliable.
• renames variable "use_proxy_always" to "always_use_proxy" to match config.

[m-schmoock]

@rustyrussell
I debugged connectd a bit and found out that my old TOR issues didn't apply to recent versions anymore and always_use_proxy seems to work as intended. Anyway I tweaked code a bit...

[rustyrussell]

Minor comments: would you like to also add code to send pings to Tor connections which we initiated, every rand(30) + 30 seconds? Seems it would help with connectivity...

[m-schmoock]

@rustyrussell

I'm not too sure about the each 30secs ping on TOR connections just yet as there are some open questions:

• What do we do if we don't get a response in time?
• Should we kill the connection and retry?
  • If yes, after which timeout?
  • If no, what does the ping achieve? (Just hope that TOR does better internal magic?)
• Is 30secs a good value for TOR?

Also Bolt#1 tells us using frequent lightning protocol pings can raise a problem:

	/* BOLT #1:
	 *
	 * A node receiving a `ping` message:
	 *  - SHOULD fail the channels if it has received significantly in
	 *    excess of one `ping` per 30 seconds.
	 */

When a connection gets laggy and say its TCP socket suddenly spits out 2minutes of 'old remote data' to the daemon (which happens on TCP over TOR), there may be implementations that then fail the channels as it would receive 4 pings at once and they can't know that they were actually distributed 'evenly' over the past 2 minutes.

[rustyrussell]

@rustyrussell

I'm not too sure about the each 30secs ping on TOR connections just yet as there are some open questions:

It's a separate PR, but I think it would be useful.

* What do we do if we don't get a response in time?

* Should we kill the connection and retry?

My advice: only send a ping if you made the connection (no point both sides doing it, might as well establish a convention).

  * If yes, after which timeout?
  * If no, what does the ping achieve? (Just hope that TOR does better internal magic?)

I think if you're trying to send the next ping and you haven't got the reply from the last, you close the connection.

* Is 30secs a good value for TOR?

Well, if we can't get an HTLC committed (add, commit) in 30 seconds we already kill the connection and fail the HTLC, and we won't send the commit unless we've heard from the peer in the last 30 seconds (in which case we ping).

So if your connection is slower than that, c-lightning isn't going to work. And while we could extend that, it's pretty unfriendly to the rest of the network.

Also Bolt#1 tells us using frequent lightning protocol pings can raise a problem:

	/* BOLT #1:
	 *
	 * A node receiving a `ping` message:
	 *  - SHOULD fail the channels if it has received significantly in
	 *    excess of one `ping` per 30 seconds.
	 */

When a connection gets laggy and say its TCP socket suddenly spits out 2minutes of 'old remote data' to the daemon (which happens on TCP over TOR), there may be implementations that then fail the channels as it would receive 4 pings at once and they can't know that they were actually distributed 'evenly' over the past 2 minutes.

No, because you are also not supposed to send one until you've got the previous reply.

Note that channeld already has some ping logic, and it's probably a good place to start with this for Tor.

[rustyrussell]

Ack da0440e