Update protocol for continuous inbound liquidity

[t-bast]

We revamp our protocols for on-the-fly funding to use a unified approach based on liquidity ads. We simplify messages exchanged and reduce the number of custom extensions required on top of the BOLT specifications.

We also introduce an optional fee_credit feature, that is disabled by default (because it introduces an additional trust trade-off with the service provider), which allows wallets to accept small payments for which an on-chain operation is not economical, and obtain a fee credit in exchange for a future on-chain operation.

The main changes to the protocol are:

• the wallet initiates all channel operations (it is responsible for sending open_channel2 and splice_init)
  • it thus automatically pays the on-chain fees for the common transaction fields, as specified by the interactive-tx protocol
  • it uses a custom channel flag to ask the service provider to pay the commit tx fees and closing fees (won't be necessary anymore once we use 0-fee commit txs with package relay), which enables 0-reserve and allows emptying a wallet using an off-chain payment
• we replace the pay_to_open messages with a single maybe_add_htlc message, which is a clone of update_add_htlc without a channel_id or htlc_id:
  • the wallet processes them in the IncomingPaymentHandler
  • if it wishes to fulfill them, it reveals the preimage in open_channel2 or splice_init:
    • the service provider will push the corresponding amount
    • the wallet must also buy inbound liquidity at the same time, which ensures that:
      • some fees are paid to the service provider
      • future payments may be received without requiring an on-chain operation
      • the service provider has enough funds on their side for the commit tx fees
    • if disconnected, the service provider will remember how much it owes and the wallet can retry open_channel2 / splice_init on reconnection
      • it is now the responsibility of the wallet to initiate that operation, which simplifies state tracking on the service provider side
  • if it doesn't want to fulfill the corresponding payment, the wallet simply ignores the maybe_add_htlc message: the service provider will automatically fail the corresponding HTLCs after a short timeout
• the only fees that are applied are the liquidity ads fees:
  • on-chain fees for the inputs/outputs contributed by the service provider to add inbound liquidity (as specified by the liquidity ads protocol)
  • service fees for the inbound liquidity purchased (as specified by the liquidity ads protocol)

:warning: :warning: note that the DB logic changes, with the introduction of a Pending entry that must later by replaced by the final result: this must be correctly implemented on the wallet side when implementing the PaymentsDb trait! :warning: :warning: