This commit moves most of the code into its own package. It is
the smallest code move possible without moving import cycles and
keeping the changes to the code base as small as possible during
refactor.
This method is not only used by the payment logic so we need to
move it to a generalized place because in the following commits
we move payment related code into its own package.
We introduce a new package paymentsDB and start by moving the
payment specifc errors from the channeldb package to the
paymentsDB package. We also fix linter issues which showed up
due to changing this code part.
We add a context for the query method because the query method
is part of the paymentDB interface and for the SQL case
we will need the context for this method because the native
SQL drivers demand one. So we add it for the kv implementation
here as well so we can then make use of the new interface type.
This error is returned when one attempts to use taproot overlay channels
without the necessary auxiliary funding controller being supplied. In
practice, when running lnd via litd, the latter will always supply
'tapd' as the aux funding controller, but a standalone lnd has no
knowledge of that.
The previous message sort of reads like the lnd user has forgotten to
set some available option or flag, but nothing or the sort actually
exists. The update makes it clearer that the feature isn't available in
the standalone build.
To make sure we don't cause force-closures because of commit sig
mismatches, we add a test case to verify that the retransmitted HTLC
matches the original HTLC.
We update the lightning channel state machine in some key areas. If the
noop TLV is set in the update_add_htlc custom records then we change the
entry type to noop. When settling the HTLC if the type is noop we credit
the satoshi amount back to the sender.
We add a new update type to the payment descriptor to describe this new
type of htlc. This type of HTLC will only end up being set if explicitly
signalled by external software.
We check the context of the payment lifecycle at the beginning of
the `resumepayment` loop. This will make sure we have always the
latest state of the payment before deciding on the next steps in
the function `decideNextStep`.
The following performance gains were measured using the new benchmark
test.
```
name old time/op new time/op delta
ChanUpdatesInHorizon-native-sqlite-10 18.5s ± 3% 2.0s ± 5% -89.11% (p=0.000 n=9+9)
ChanUpdatesInHorizon-native-postgres-10 59.0s ± 3% 0.8s ±10% -98.65% (p=0.000 n=10+9)
```
Let the helper method only take the params it needs so that we dont need
to construct an entire models.ChannelEdgeInfo object to pass to it. This
will be useful later on.
