feat!: use libtor to spawn in-process Tor for base node and console wallet

[delta1]

Description

• base node and console wallet default to starting their own Tor instance
• 2 adjacent ports are selected from given range and tested to be available (this is for control and socks ports, not for the onion port)
• random password is generated and configured
• data directory and logging file are temporary
• new config option use_libtor for [base_node.network] and [wallet.network] defaults to true, when set to false allows Tor comms transport to be manually defined as before

Motivation and Context

Improved user experience - ease of getting started without requiring separate Tor

How Has This Been Tested?

Tested by setting up new base nodes and wallets and running them using libtor, and also tested that they still work using a system level Tor.
TODO: still to be tested on Windows

Breaking change: old config files might no longer work

[delta1]

Going to need an update for build base node binaries CI

[sdbondi]

Awesome, very cool that tor can be embedded. Changing the address each time will cause connectivity issues that can be hard to debug (nodes not connecting when they are online, not noticing the address has changed)

[delta1]

Breaks the build on windows, looking for a solution

[delta1]

Awesome, very cool that tor can be embedded. Changing the address each time will cause connectivity issues that can be hard to debug (nodes not connecting when they are online, not noticing the address has changed)

Just to clarify - the public address remains the same and is loaded from the node identity file, it is just the Tor control port and socks port that are checked for availability in the port range and selected.

[sdbondi]

it is just the Tor control port and socks port that are checked for availability in the port range and selected.

Ok cool, sounds good. Then downgraded to a nit, maybe Tor::randomize could be Tor::initialize and remove the port range.

Warning about port bind test (from experience), the port may stay bound after the test even if it's dropped on linux (unless SO_REUSEPORT is used subsequently). You can let the OS assign an open port by using port 0

[sdbondi]

Just remembered, if you set both of these to 0 the OS will assign an open port.

[delta1]

In that case does the bind return the port number?

[delta1]

Okay I see I can use local_addr to get it from the listener. Will do

[delta1]

it is just the Tor control port and socks port that are checked for availability in the port range and selected.

Ok cool, sounds good. Then downgraded to a nit, maybe Tor::randomize could be Tor::initialize and remove the port range.

Warning about port bind test (from experience), the port may stay bound after the test even if it's dropped on linux (unless SO_REUSEPORT is used subsequently). You can let the OS assign an open port by using port 0

Agreed sounds good

[delta1]

Windows compilation issues would either require building via cygwin/mingw/msys2, or maintaining a fork and migrating the tor source to cmake for windows, both of which are undesirable for this feature.

Closing this PR and will re-open as an opt-in feature for linux/macos only, unfortunately.