htlcswitch: add p2p inbound fee

[joostjager]

Alternative to gossip-based inbound routing fees as implemented in #6703. Idea mentioned in lightning/blips#18 (comment), apparently originally proposed by @rustyrussell.

Summary

A node A can give its peer B a discount for routing through them. Assuming market forces do their work, this allows the peer B to lower its outbound fee with the difference being made up by the discount. The lowered outbound fee of B is picked up by senders who may then favor that connection. Node A recovers the discount by raising its outbound fees.

Zero fee routing

If a node doesn't charge an outbound fee, they can't lower their fee any further in response to a p2p discount. If there is just one node that charges zero fee for outbound, the goal to distinguish between incoming channels can still be accomplished by giving everyone a discount except the zero fee node, and raising outbound fees accordingly. This however does not work when there are multiple zero fee nodes. Without a discount, it is not possible to make any distinction between traffic coming in through these nodes.

This is a limitation that the gossip-based proposal doesn't have.

Routing node vs final destination

When a node isn't exclusively a routing node, but also a payment destination, the node operator needs to take into account that the discount will also apply to incoming payments. This means that the paid amount may be below the invoice amount. There doesn't seem to be a way around this without its predecessor knowing whether they are forwarding to an intermediate or a final hop.

An alternative is to set up a virtual destination node and charge an outbound fee for the virtual channel. Note that in that configuration, there is only a single outbound fee. WIth differing fees on the incoming side, it won't be possible to match those exactly with the outbound fee. To ensure that at least the invoice amount is always received, the outbound fee for the virtual channel will have to be at least the maximum inbound fee (max inbound base fee + max inbound fee rate).

Incentives to upgrade

A incentive to upgrade exists, because it allows routing nodes to collect the discount. They can initially keep their own discount to zero.

The p2p inbound fee could also be positive, but that would force the counterparty to monitor the fee actively and increase their outbound rate if necessary to not lose money. If it is always negative (a discount), the routing fee earned by the counterparty can only be zero or positive.

Implementation

This PR adds a new message UpdateInboundFee that a node can send to its peer to update the inbound fee that it requires. Because htlcs to which this fee apply are travelling in the other direction, there can be race conditions. If the inbound fee is lowered (more discount), there is no problem because a higher total routing fee is accepted as well. If the inbound fee is raised, this may result in the occasional fee_insufficient failure going back to the sender. There is nothing to update for the sender though, but a retry will likely succeed as time has passed.

The remote inbound fee isn't persisted, but instead transmitted every time the link connection is re-established.

Todo:

• Set/view own inbound fees
• View remote inbound fees
• Test coverage

[joostjager]

Not actively pursuing this approach, closing for the time being.