Off-by-one when forcing feerates in the tests

[cdecker]

Issue and Steps to Reproduce

@m-schmoock identified an issue with forcing feerates:

Also I think there might be an off by one in current (master) implementation, see https://github.com/ElementsProject/lightning/pull/3572/files/7d1f8416e1af8bf9579914db46da6ce5b5cb394a#diff-e6fd9e4a383e2ab7819a6292c1edf70bR2357 for my remark in the testcase.

The code this refers to is this:

def test_lockup_drain(node_factory, bitcoind):
    """Try to get channel into a state where funder can't afford fees on additional HTLC, so fundee can't add HTLC"""
    l1, l2 = node_factory.line_graph(2, opts={'may_reconnect': True})

    # l1 sends all the money to l2 until even 1 msat can't get through.
    total = l1.drain(l2)

    # Even if feerate now increases 1.5x (22500), l2 should be able to send
    # non-dust HTLC to l1.
    l1.force_feerates(22500)
    l2.pay(l1, total // 2)

    # reset fees and send all back again
    l1.force_feerates(15000)
    l1.drain(l2)

    # But if feerate increase just a little more, l2 should not be able to send
    # non-fust HTLC to l1
    l1.force_feerates(22502)  # TODO: Why does 22501 fail? off by one in C code?
    with pytest.raises(RpcError, match=r".*Capacity exceeded.*"):
        l2.pay(l1, total // 2)

My best guess is that there is a rounding due to the feerate smoothing.

[rustyrussell]

AI cleanup of old issues. If wrong, please open a new issue.

Triage decision summary:
Off-by-one error in test fee rate forcing logic with a TODO comment suggesting uncertainty about root cause. Issue is from 2020 with no updates and appears to be a test-specific edge case rather than a critical bug.