track: Fine-tune the feerates for a variety of operations

[cdecker]

We have received several reports, and have analysed a number of nodes, that had channels with pending sweeps. The sweeps however have a rather low feerate (sometimes bumping into the lower bound of 253sat / kvB), and they therefore remain unconfirmed for prolonged periods.

This issue collects instances, and is used to discuss how we should tune the feerates.

[cdecker]

Instances

• https://github.com/Blockstream/greenlight/issues/487
• https://github.com/Blockstream/greenlight/issues/455
• https://github.com/Blockstream/greenlight/issues/453
• https://github.com/Blockstream/greenlight/issues/426

[cdecker]

I have a PR open on CLN (https://github.com/ElementsProject/lightning/pull/7528) that'll set up a finite deadline, rather than the Scrooge McDuck approach of always waiting for another 300 blocks, no matter how long we already waited.

The logic in that one is the following:

• Generally aim to confirm in less than 2 weeks
• If we are further away than 300 blocks from the deadline, use 300 blocks as a very low priority feerate
• If we are closer than 2h or even past the deadline of 2 week, use an urgent but not critical feerate estimate of 2h in the future (so we don't panic and go overboard with fees).

We are testing and will be deploying this on GL in the coming days.