Previously we would exclusively pass the autoloop boolean to multiple
functions while they had directly access to the manager's parameters.
With this commit we remove this explicit flag from the various function
interfaces and retrieve the value directly from the parameters.
This commit saves the RPC request used to construct the `Parameters` on
disk. Since it's a proto message, an easy way to read/write it is to
rely on the proto marshal/unmarshal methods. A side effect is that
migration also becomes easy as proto message have its own internal
mechanism to keep track of the compatibility.
This commit refactors the method `manager.SetParameters` to take a
`SetLiquidityParamsRequest`. As we'll see in the following commit, this
will enable us saving the params to disk more easily.
We already have a Label field in the embedded SwapContract
field for loop in swaps. This commit removes an erroneously
added Label field in LoopInContract which may be a cause of
ambiguity when referencing this field.
In preparation for adding loop in swaps, we relate liquidity rules
to a specific type of swap that we want to dispatch. This allows us
to use a single rule format for multiple swap types.
This commit adds a peer listing function to our generic swap
interface, which we will use to set reasons for swaps that are
specified by peer pubkey rather than channel.
We add 'peer-level' rules to allow assessment of liquidity on a per-peer
level, rather than on an individual channel basis. No overlap is allowed
with the existing set of channel rules because this could lead to
contradictory rules.
In practice, this restriction has proven to be too strict. Autoloop will
now only hold off on a swap for a channel if a manual swap is
specifically using that channel.
In an effort to surface more information about why autoloop is not
executing, we add an error when suggest swaps is called with no rules.
In other cases we can surface a reason enum with each rule that is set,
but in the case where we have no rules, there are no results to
accompany with reasons.
Add a dated fee budget to our swap suggestions. This budget only applies
to automatically dispatched swaps (which will be added in later
commits). We choose to apply the fee budget to our suggestions so that
they perfectly replicate what the autolooper would do. The budget has a
start date so that it can be refreshed once it has been used up over a
period (rather than having to endlessly increase it).
As we add more parameters in this PR, we wil want to test values
beyond our default values. This commit updates the suggest swaps test
helper to take a full setup struct, and adds a default set of channels
and rules which will be used in the absense of this setup struct.
To decide whether we event want to attempt a swap, we add a fee limit
that we check against our estimate for the current number of
confirmations we want our sweep to confirm in. If fees are higher than
this limit, we do not suggest swaps.
This commit updates swap suggestions to return loop out requests with
sufficient fields populated so that a loop out can directly be
dispatched from a suggestion. This requires setting of fees an min
sweep conf targets (our htlc conf target and addresss will be set by
the daemon's client rpc server if we do not provide them). We also do
some test refactoring so that we can more easily test the suggest swaps
endpoint.
