contractcourt: don't factor in dust HTLCS into go-to-chain decisions

[Roasbeef]

In this commit, we modify our go to chain heuristics to ensure that we won't force close due to dust HTLCs. Dust HTLCs can't actually be claimed on chain, so we only have a direct cost by going on chain.

This is a very simple PoC implementation, to demonstrate a possible fix. In the past, there were questions on if this violated the spec as it states:

if an HTLC which it offered is in either node's current commitment
transaction, AND is past this timeout deadline: MUST fail the channel.

Where fail the channel here means to force close. However, it's easy to come up with some scenarios (namely high chain fees) where it doesn't make economic sense to go to chain with a very small valued HTLC. As a force close is required, the on chain fee needs to be paid, and also the funds are locked for the CSV duration.

We can further extend this logic by integrating components of #3955 that attempts to compute the total sweep cost for an HTLC. This'll expand the heuristic to keeping the channel open for very small HTLCs, that may actually be beyond dust.

One down side of this type of change is that these HTLCs will still occupy space towards the current 488 HTLC limit. In the past, it had been suggested that we should actually have two limits: one for dust HTLCs, and one for regular HTLCs. In the future, we may be able to introduce this extra set of flow control constraints using dynamic commitments.

Fixes #1226

Change Description

Description of change / link to associated issue.

Steps to Test

Steps for reviewers to follow to test the change.

Pull Request Checklist

Testing

• Your PR passes all CI checks.
• Tests covering the positive and negative (error paths) are included.
• Bug fixes contain tests triggering the bug to prevent regressions.

Code Style and Documentation

• The change obeys the Code Documentation and Commenting guidelines, and lines wrap at 80.
• Commits follow the Ideal Git Commit Structure.
• Any new logging statements use an appropriate subsystem and logging level.
• There is a change description in the release notes, or [skip ci] in the commit message for small changes.

📝 Please see our Contribution Guidelines for further guidance.

[Roasbeef]

I think what was missing in the initial PR that that attempted to fix this is that: when when we make a decision to not go to chain due to dust, we should also just cancel back that HTLC. We're essentially taking the loss off-chain, rather than going on chain and disrupting the channel.

After we cancel back we still have that outgoing HTLC, but if it gets redeemed then we lose that amount along and also forfeit the routing fee. Or maybe it eventually gets failed too, but much later (no loss, no gain). From there we can create a risk model based on the active amount of deficit HTLCs to model the worst scenario that leads to a lopsided redemption (settle outgoing, can't settle incoming).

A routing node's risk tolerance can be used as a parameter to gauge how much HTLC deficit a node has racked up before we start to go back to normal go-to-chain decision. In the end though, the freed up commitment space may help pay off the deficit over time (routing fees starting from the point where you make the decision to be on the hook for the HTLC).