smite-ir: add RecvShutdown operation

[ekzyis]

This implements the RecvShutdown operation for #98.

TODO:

• verify if received shutdown has standard shutdown script (#186)
• verify if received shutdown matches channel id we'd expect
• consider upfront_shutdown_script
• use SentShutdown(ChannelId) and check peer_shutdown_received for that channel in is_shutdown_expected
• validate upfront_shutdown_script in AcceptChannelOracle
• add tests for ShutdownOracle

[NishantBansal2003]

I think this needs to be rebased on top of #162 to consume the affine type SentShutdown

[morehouse]

I think we want the affine type wired in for sure.

But that probably isn't enough -- we can't expect the target to send us a shutdown message until all HTLCs have been resolved as well. There's also probably a case where we could send two shutdown messages and the target may ignore any of them after the first one.

I think for the HTLCs we can't really implement that part until #111 is implemented, so we can just add a TODO for that.

For the duplicate shutdown case we could probably add a flag to the channel state that indicates whether the peer has already responded to the first shutdown, and if they have then any subsequent RecvShutdown message becomes a no-op (similar to RecvChannelReady).

[ekzyis]

I think for the HTLCs we can't really implement that part until #111 is implemented, so we can just add a TODO for that.

Added TODOs in 77cf4f8. I thought it would be useful to group all HTLC TODOs together with TODO(htlc) as the prefix, so I updated the existing HTLC TODOs in c9a2c60:

$ git grep "TODO(htlc)"
smite-scenarios/src/executor.rs:                    // TODO(htlc): we only expect `shutdown` when all HTLCs are resolved, else this
smite/src/channel_tx/commitment.rs:    // TODO(htlc): When adding HTLC support, store pending HTLCs (offered/received) for both sides
smite/src/channel_tx/commitment.rs:    // TODO(htlc): When adding HTLC support, add `get_next_commitment_state` to build the next
smite/src/oracles/shutdown.rs:        // TODO(htlc): BOLT 2 forbids sending `shutdown` while HTLCs are still pending

---

For the duplicate shutdown case we could probably add a flag to the channel state that indicates whether the peer has already responded to the first shutdown

We now check in 77cf4f8 if we expect a shutdown on any channel. Only then we wait for a shutdown response. We don't know on which channel we will receive a shutdown, but I could change SentShutdown to SentShutdown(ChannelId), then we would know (just realized while typing this).

TODO:

• use SentShutdown(ChannelId) and check peer_shutdown_received for that channel in is_shutdown_expected

---

Mhh, I wonder if there's a conflict between this (#163 (comment)):

I think this should output the spk so it can be used in subsequent channel closing messages, otherwise, we will always be rejected in those cases later

and this (#163 (review)):

if they have then any subsequent RecvShutdown message becomes a no-op (similar to RecvChannelReady).

In 77cf4f8, RecvShutdown returns empty bytes as a sentinel similar to LookupShortChannelId when no shutdown is expected on any channel. It's clearly an invalid shutdown script. Could this be a problem for downstream consumers of its return value, who might expect a valid shutdown script? Should they then also be no-ops, at least in the case of RecvShutdown?