This commit adds a PendingCommitTicker to the link config, which allows
us to control how quickly we fail the link if the commitment dance
stalls. Now that the mailbox has the ability to cancel packets, when the
link fails it will reset the mailbox packets on exit, forcing a
reevaluation of the HTLCs against their mailbox expiries.
Now that packet failure is handled by the mailbox, we can now enforce
a delivery deadline and fail the packet if it the deadilne is exceeded.
This gives senders quicker feedback about tried routes, and allows them
to try alternative paths to the destination in the meantime.
This commit splits the packet courier internally into two distinct
queues, one for adds and one for settles+fails. This allows us to
prioritize HTLCs that will clear the commitment transaction and make
space for adds. Previously this responsibility was handled by the
overflow queue.
This commit delays the advancement of the pktHead until after the
message has been delivered. This is a prepatory step, as in the future
we may fail to deliver the packet due to a deadline expiring.
This commit moves the current logic for sending failures out of the link
and into the mailbox in preparation for our failing delayed htlcs. We do
so because the mailbox may need to fail packets while the link is
offline, and needs to be able to complete the task without member
methods on the link.
This is less brittle than blacklisting states since it may not be clear
that new states needs to be added. Now that HasChanStatus is fixed for
ChanStatusDefault, we can safely implement this.
This addresses a bug in which a funding reservation wasn't cleaned up
properly if the remote peer didn't support upfront shutdown.
Alternatively, we could just cancel the reservation on error, but
instead we move the check above so that we don't attempt coin selection
in the first place.
We'll do the validation during construction of the runtime so that we
can safely use the AppPreRelease field externally without needing to
normalize it.
This commit removes ChanStatusDefault from the list of
orderedChanStatusFlags since it is not flag. As with the prior commit,
the logic around these flags assumes everything in the list is a flag,
but ChanStatusDefault is not.
It turns out we properly special case that if the channel is in
ChanStatusDefault that we only return ChanStatusDefault. However, if any
of the bits are set we would always report ChanStatusDefault since
status&0 == 0. This fixed simply by removing ChanStatusDefault from the
list since we only need the list to express non-default status flags.
