Resending revoke_and_ack and commitment_signed (+update) messages
after monitor-update-failure or disconnection has been a highly
unreliable part of our codebase for some time (as evidenced by the
number of bugs caught in the chanmon_fail_consistency fuzz target).
This is due to its rather ad-hoc nature and tracking/behavior which
consists of checking a number of different flags to try to deduce
which messages were/were not delivered and go from there. Instead,
this commit rewrites it to simply keep track of the order messages
were generated originally, as we always resend in the
originally-generated order.
I'm anticipating this will be way more robust than the old code, in
addition to its simplicity.
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.
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.
ie dont generate them as they're a really obvious privacy leak.
Luckily we were already handling them the same aside from log
printing so don't have to touch anything there. I was lazy in
updating tests but it only effects log printing, so whatever.
Also be willing to forward something with a pubkey that we know is
complete garbage, but upstream will just fail that with BADONION
when they get it.
I think this is kinda intended by the spec, but it definitely needs
to be clarified.
This is somewhat awkward, but prevents a slew of duplicate events.
Really this should probably be more explicit, but would be easy to
move that along with a slew of block_connected-event-processing
refactors, see-also GH #80.
This affects full_stack_target only on accident cause the demo test
didn't continue onwards with another block connection.
Called in ChannelMonitor block_connected, returning
HTLCUpdate upstream via ManyChannelMonitor to
link htlcs between monitors. Used by ChannelManager to
fulfill/fail htlcs backwards accordingly
If spurrious HTLCUpdate are generated due to block re-scan
and htlc are already LocalRemoved, discard them in
channel get_update_*_htlc
