`max_htlc_dust_exposure_msat` and MPP interaction

[niftynei]

As pointed out on #4837, MPP and max_htlc_dust_exposure_msat have a potential to collide and result in an MPP timeout/failure, depending on the routes that are being used.

c-lightning's default for max_htlc_dust_exposure_msat is 50k sats; if you attempt to send a 50k sat payment in parts that are considered dusty and those parts are all routed through the same c-lightning channel in the middle, then the payment will fail since the middle link wasn't able to accept them as htlcs.

I'm not sure what the right solution is here. The dust_exposure_msat is settable by the individual node, so we don't know exactly how much dust they'll accept. We also don't know what other htlcs are occupying that limit at the time of sending.

Further, what's considered dusty is variable, so high fee regimes will most likely result in MPP payment failures increasing.

Here's a few suggestions on how to deal with this on the MPP split side:

• Vary the size of the MPP payment according to the current feerate regime,
• Correlated, where possible make all MPP splits bigger than what's currently considered 'dusty'

[ZmnSCPxj]

This seems like something that forwarding nodes need to gossip, so probably deserves protocol change? Kinda leaks information on your view of the mempool, but mempools are not-quite-inconsistent so maybe does not really leak (that much) info? Consider -- if most of the network is raising their dustlimit and you are not, you might not have an up-to-date mempool and attacking you with mempool shenanigans might be a good idea...?