Allow HTLC receiver to dip into channel reserve

When an HTLC is added, the size of the commitment transaction increases
while that HTLC is pending, which also increases the on-chain fee that
the channel initiator must deduce from its main output.

Before sending an HTLC, when we're not the channel initiator, we thus
must ensure that our peer has enough balance to pay for the increased
commitment transaction fee. We previously went further than that, and
also required that our peer stayed above their channel reserve.

That additional requirement was unnecessary, and there was no matching
receiver-side requirement, so it should be safe to delete.

It makes a lot of sense to allow the HTLC receiver to dip into its
channel reserve to pay the fee for an HTLC they're receiving, because
this HTLC will either:

- be failed, in which case the balance goes back above channel reserve
- be fulfilled, in which case the balance increases which also helps
  meet the channel reserve

This also prevents channels from being stuck if the reserve becomes
dynamic (which will be the case with splicing). Without that change,
we can end up in a situation where most of the channel funds are on
the non-initiator side, but they cannot send HTLCs because that would
make the initiator dip into their reserve to pay the increased fee.

02-peer-protocol.md

@@ -1017,8 +1017,8 @@ A sending node:
   - if it is _not responsible_ for paying the Bitcoin fee:
     - SHOULD NOT offer `amount_msat` if, once the remote node adds that HTLC to
     its commitment transaction, it cannot pay the fee for the updated local or
-    remote transaction at the current `feerate_per_kw` while maintaining its
-    channel reserve.
+    remote transaction at the current `feerate_per_kw` (but it is allowed to
+    go below its channel reserve to pay the fee)
   - MUST offer `amount_msat` greater than 0.
   - MUST NOT offer `amount_msat` below the receiving node's `htlc_minimum_msat`
   - MUST set `cltv_expiry` less than 500000000.