smite-ir: add SendError and SendWarning operations and generators

[erickcestari]

Adds SendError and SendWarning operations plus a generator for each, so programs can send BOLT 1 error and warning messages and exercise the target's error handling and force-close paths. The generators use the all-zero channel_id one time in four to cover the "all channels" case.

Closes #256

[erickcestari]

At the current state of the PR, adding SendError breaks AcceptChannelOracle for LDK (I haven't tested it with other implementations yet), because LDK accepts a new open_channel with the same temporary_channel_id after the first one has been errored out.

INFO  [smite::scenarios] Scenario initialized! Executing input...
INFO  [smite::runners] Reading input from "/input.bin"
DEBUG [smite_scenarios::scenarios::ir] [14.642µs] Executing IR program (138 instructions, 1674 input bytes)
DEBUG [smite_scenarios::executor] [630.406µs] SendOpenChannel: 331 bytes
DEBUG [smite_scenarios::executor] [812.627µs] RecvAcceptChannel: waiting
DEBUG [smite_scenarios::executor] [2.305253ms] RecvAcceptChannel: received
DEBUG [smite_scenarios::executor] [2.421323ms] SendError: 36 bytes
DEBUG [smite_scenarios::executor] [2.510861ms] SendOpenChannel: 331 bytes
DEBUG [smite_scenarios::executor] [2.516255ms] RecvAcceptChannel: waiting
DEBUG [smite_scenarios::executor] [3.631017ms] RecvAcceptChannel: received
ERROR [smite::runners] Test case failed: invalid accept_channel for temporary_channel_id 33c6df673bcc970e0d07f771b2dbe842304a1bf40a4527f5a450927e0f78a817: temporary_channel_id reuse: previous negotiation has not reached funding_created

[erickcestari]

Added OrphanedAccepts to count accept_channel replies still in flight for negotiations we failed with an error before receiving them. A reply still in flight when the error is sent is validated against the failed negotiation instead of being reported as unknown.

[ekzyis]

re: #257 (comment)

A reply still in flight when the error is sent is validated against the failed negotiation instead of being reported as unknown.

I don't know how relevant this is (currently), since we don't open multiple channels afaik, but if the target never replies to the first open_channel but accepts a second open_channelwith the same temporary_channel_id, we will think the received accept_channel is orphaned:

SMITE (us)                                 TARGET
   |                                          |
   |------------ open_channel (X) ----------->|
   |                                          |
   |--------------- error (X) --------------->|
   |                                          |
   |------- open_channel (X, reuse) --------->|
   |                                          |
💥 |<---------- accept_channel (X) -----------|
   |                                          |

Is this a problem?

[ekzyis]

nit: Mhh, I would prefer if we could add this to negotiations somehow. I think the problem is that negotiations currently only tracks the latest negotiation per temporary_channel_id, but for orphans, we need to track "pending negotiations", too.

Maybe negotiations should be refactored to support this, instead of adding another global executor map? For example, we could use a new ChannelNegotiation struct instead of PendingChannel for negotiations:

struct ChannelNegotiation {
  live: Option<PendingChannel>, // current negotiation, if any
  awaiting_orphan_reply: VecDeque<PendingChannel>, // failed, reply maybe in flight
}