This is required by BOLT 2 to ensure that no attacker can simply
relay every public node a duplicate-payment_hash HTLC for each HTLC
it receives to deduce where an HTLC came from.
Note that this makes the claim logic much less incentive-compatible
as we will not claim all available HTLCs with the same payment_hash
even if we know the preimage! This is OK because, most likely, any
attackers trying to map the network will use small-value payments
and, hopefully, we will move away from constant hashes across an
entire payment at some point in the near future.
This further simplifies the payment transition state a bit, so
hopefully at least we got some readability out of all of this
Because we don't have an HTLCState for
update_add_htlc-generated-but-not-yet-commitment_signed to simplify
the mess of HTLCState match arms, any time a Channel::send_htlc
call returns Ok(Some(_)) we MUST call commitment_signed and it MUST
return success (or close the channel). We mention this in the docs
and panic if its not met in ChannelManager (which lets the fuzz
tester check this).
Because we've separated out channel closure from ErrorMessage
returning we can return error messages in a few additional cases,
like if the peer sent us a message for a channel they didn't own.
This resolves a spec-compliance bug with BOLT 4 where we simply
failed to deserialize the message and thus could never return an
HTLC failure message. However, note that BOLT 4 incorrectly hints
that a non-malformed message should be used ("...MUST report a
route failure to the origin node") which we cannot do as we cannot
derive a SharedSecret to encrypt a regular update_fail_htlc message
UpdateFailHTLC isn't really an error anymore now that its handled
async after channel commitment (as required by BOLT 2), and since
its unused this is free. To resolve the TODO which intended to use
it for HTLC failure when trying to route forwards, we instead opt
to merge all the HTLC update events into one UpdateHTLCs event
which just contains a CommitmentUpdate object.
This fixes a violation of BOLT 2 and will let us consolidate some
HTLC update handling. Good bit of code movement, but is mostly
refactor to store HTLC failure status in pending_htlcs in Channel.
