Broadcasting a commitment tx means that we have to fail
inbound HTLC in backward channel. Doing it prematurely would
put us at risk in case of reorg. So we delay passing failure
update upstream until solving tx mature to HTLC_FAIL_ANTI_
REORG_DELAY.
Requirements differ if HTLC is a revoked/non-revoked dust/
non-revoked non-dust one.
Add connect_blocks in test_utils to fix broken tests due to
anti-reorg delay enforcement
Remove anti-duplicate htlc update stuff in ManySimpleChannelMonitor
Previously, if we went to free the holding cell HTLC updates, and
adding one failed as we hit our outbound HTLC limit (or in-flight
value limit), we would not send a commitment_signed, leaving us in
an invalid state. We first fix that bug, and then refuse to add
things to our holding cell once we reach our limits considering the
holding cell, as we shouldn't have multiple commitment dance rounds
worth of HTLCs in the holding cell anyway.
Primarily this fixes the case where we receive an RAA which does
not require a response, allowing us to call monitor_update_failed
without generating pending messages.
This resolves a TODO/issue in would_broadcast_at_height where we
will not fail a channel with HTLCs which time out in remote
broadcastable transactions.
When our counterparty claims multiple HTLCs from offered outputs in
one transaction we should still be able to learn the preimages.
Sadly, due to two bugs we were not previously doing so.
This tests a case we previously didn't handle correctly where we
returned early if there was no to_remote output to claim and thus
failed to fail-backwards HTLCs which were present.
