generate a static tor onion address persistent unique to the node id

[Saibato]

We now can generate a V3 tor service address from a blob

--addr=statictor:127.0.0.1:9051[/torblob=[blob]]

Or generate a unique static tor address bound to our node id /pub key

--addr=statictor:127.0.0.1:9051

TODO:

• Documentation

• Write some simple py-tests

EDIT: With this you are able to keep your public known or group known tor address static
and independent of torrc file or the tor instance ( if multiple ), in case you have to
move your node to an other PC or system/phone, as long as there is a tor service
your node will be reachable even if ip, NAT, firewall have changed by that static V3 address.

EDIT: related issues #2476 #3085

EDIT_2:

With this PR we can now also select the extern tor port we assign our local port to

--addr=statictor:127.0.0.1:9051[/torblob=[blob]][/torport=EXTERNPORT]

Or generate a unique static tor address bound to our node id /pub key

--addr=statictor:127.0.0.1:9051[/torport=EXTERNPORT]

[Saibato]

@cdecker rebased and ready to rumble ... 👍

[cdecker]

There is a lot of error-prone string parsing in the PR, I wonder if using
tal_strreg
might simplify the code and make it more flexible for future changes.

As it is now this resembles more a key-value bag than an address, so maybe we
should embrace that and actualy use : as the key-value separator in a stream
of pairs that use a different separator? Similar to the URL encoding commonly
used on the web, and making the relationship beween torport and 45321
clearer (I fell for that myself, not realizing that these are effectively
key-value pairs and not understanding the format 🙁). We are using /
elsewhere in the RPC as separator sometimes.

If we were to introduce backwards incompatible changes I'd advocate for a
format similar to this:

statictor=127.0.0.1:9151/torport=45321/torblob=11234567890123456789012345678901

The use of : as separator is really causing a bit of trouble since it is
commonly used as <address>:<port> separator, and for internal formatting of
IPv6 addresses (who came up with that design...🤬)

As a side note, I had to review this as a complete diff, since the incremental changes made it really hard to analyse the commits individually (I'd also be doing a squash merge on this since we can't guarantee bisectability).

We tend to normally have self-contained commits that are minimal in what they do, and then we fix them up using either fixup! commits (like I usually do) or by amending commits in-place (rusty uses guilt iirc). Both methods result in a clean and easy to follow commit history that is easier to review, and to audit later, whereas just adding incremental changes in cleanup commits added to the end of the PR make things hard. I'd strongly suggest using ones of those processes for future pull requests 😉

[Saibato]

addressed the most/all points of your review. Thanks. 👍
Please review again

Its now rebased, bisectable and structured in 3 parts.

[Saibato]

A bit of side show, but almost all PR not only this, fail the Travis lottery on first or second push with random errors unrelated to the changes.
@rustyrussell @cdecker #3286 solved all ? Travis failed https://travis-ci.org/ElementsProject/lightning/builds/616642255?utm_source=github_status&utm_medium=notification
I will now force push the same PR again and again 🤦‍♀️ until I win the Travis check lottery 🎲 🎲 🎲 take two won ...

[cdecker]

A bit of side show, but almost all PR not only this, fail the Travis lottery on first or second push with random errors unrelated to the changes.
@rustyrussell @cdecker #3286 solved all ? Travis failed https://travis-ci.org/ElementsProject/lightning/builds/616642255?utm_source=github_status&utm_medium=notification
I will now force push the same PR again and again until I win the Travis check lottery take two won ...

I'm restarting failed tests and keeping track of which tests were flaky, so you don't need to push just to get Travis to like your PR 😉

Pushing the same PR just to retry Travis just makes tracking changes rather hard: http://46.101.246.115:8888/ElementsProject/lightning/pull/3155

[cdecker]

Excellent changes @Saibato, sorry for the delay in reviewing it 👍

ACK 14882ec

[jb55]

very cool, thanks @Saibato !