In this commit, we add a new build tag protected sub-config for legacy
protocol features. The goal of this addition is to be able to default to
new feature within lnd, but expose hooks at the config level to allow
integration tests to force the old behavior to ensure that we're able to
support both the old+new versions.
With the introduction of the WatchtowerClient RPC subserver, the lnd
configuration flag to specify private watchtowers for the client is no
longer needed and can lead to confusion upon users. Therefore, we remove
the flag completely, and only rely on the watchtower client being active
through a new --wtclient.active flag.
Start the Prometheus exporter in rpcserver.go if monitoring is enabled through the
build tag. Also allow users to specify what address they want the Prometheus
exporter to be listening on.
Now that the write pool no longer executes blocking i/o operations, it
is safe to reduce this number considerably. The write pool now only
handles encoding and encryption of messages, making problem
computationally bound and thus dependent on available CPUs. The
descriptions of the workers configs is also updated to explain how users
should set these on their on machines.
TCP addresses resolved through net.ResolveTCPAddr give a default network
of "tcp", so we'll map back the correct network for the given address.
This ensures that we can listen on the correct interface (IPv4 vs IPv6).
This commit introduces the Validator interface, which
is intended to be implemented by any sub configs. It
specifies a Validate() error method that should fail
if a sub configuration contains any invalid or insane
parameters.
In addition, a package-level Validate method can be
used to check a variadic number of sub configs
implementing the Validator interface. This allows the
primary config struct to be extended via targeted
and/or specialized sub configs, and validate all of
them in sequence without bloating the main package
with the actual validation logic.
Bumps the default read and write handlers to be well
above the average number of peers a node has. Since
the worker counts specify only a maximum number of
concurrent read/write workers, it is expected that
the actual usage would converge to the requirements
of the node anyway. However, in preparation for a
major release, this is a conservative measure to
ensure that the default values aren't too low and
improve network instability.
