Handle htlc_max != channel capacity better in scoring

[TheBlueMatt]

There's two issues today with the way we handle channels with an htlc-max being different from the channel's capacity (which historically was never a thing but we expect to happen more over time, so should support it now):

• some users expect to operate without validating on chain UTXOs. We should (a) ensure rapid gossip sync includes actual channel capacity and (b) update docs to make clearer that without validation of UTXOs we will score incorrectly,
• we may think the channel balance available is incorrect as we calculate based on the wrong value. This may mostly already be right but one concern is how do we differentiate between a channels max-in-flight being maxed out vs the channel's balance being actually maxed out. It's unclear to me that that's possible or how we'd account for it.

[jkczyz]

• we may think the channel balance available is incorrect as we calculate based on the wrong value. This may mostly already be right but one concern is how do we differentiate between a channels max-in-flight being maxed out vs the channel's balance being actually maxed out. It's unclear to me that that's possible or how we'd account for it.

To add more context and clarification, the EffectiveCapacity of the channel is used during scoring. Currently, the channel capacity is preferred over htlc_maximum_msat for the EffectiveCapacity when both are know. If the capacity is unknown, htlc_maximum_msat is used.

[tnull]

I plan to pick this up eventually.

[TheBlueMatt]

I think the only real TODO here is to include channel capacities in RGS data.

[tnull]

I think the only real TODO here is to include channel capacities in RGS data.

Hmm, right. I wonder if it would make sense to hold off on it a bit further then until splicing is in, as we might need to make adjacent changes for splicing compatibility?

[TheBlueMatt]

From the PoV of gossip splices are just "new channels between the same nodes". I don't see a reason why we'd treat it differently in RGS (it would be nice to keep scoring data across splices, but we'd have to account for the splice, so that seems like very much future work, and if we get there we can include the "previous SCID this spliced" field from gossip in the RGS data as well without much hassle, so I don't think it'd be a big shift).