This should probably have happened when we moved most state into
the state enums themselves, but specifically forcing awareness of
the removed/not removed state would have prevented me from
introducing a bug in the first version of an upcoming reserve-value
patch.
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.
This shouldn't be required, but it may help prevent some downstream
race conditions due to clients not sending message events quickly
enough and trying to send stale messages before new
channel_reestablish messages.
This fixes a rather subtle case handling RAAs when we don't
generate a response due to a previous monitor update failure, but
would otherwise send a CS response. We need to still set
AwaitingRemoteRevoke on the channl in question, but previously did
not. Found by chanmon_fail_consistency fuzz test with the failing
test converted and added manually.
Extend route_test to check if serialize/deserialize of
NetworkMap works.
Add PartialEq traits on some Router's structs.
Modify also UnsignedNodeAnnouncement serialization
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.
We really shouldn't have split out the with-source HTLCs from the
in-transaction HTLCs when we added back-failing, and will need
almost all of the info in HTLCOutputInCommitment for each HTLC to
fix would_broadcast_at_height, so this is a first step at
recombining them.
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.
