Allow sending closing tx signatures asynchronously

[alecchendev]

Another async signing PR, this time for sign_closing_transaction!

If you've reviewed the other PRs, you know the drill: try to go about business as usual, if we fail to get the signature, do everything except for send the message, and mark our signer_pending_closing flag. The user then needs to call signer_unblocked, and we'll try again to get the signature, then create + send the message. In this case we not only need to send the message, but also 1. broadcast the fully signed closing tx, 2. broadcast a channel update, and 3. remove the channel from our map.

I added some additional state to track everything we need to do everything we need (rebuild the tx, fully sign, send our closing_signed msg, etc.) upon the signer being unblocked. This state is not persisted.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 86.36364% with 9 lines in your changes missing coverage. Please review.

Project coverage is 91.12%. Comparing base (33e6995) to head (6e2071a).
Report is 108 commits behind head on main.

Files	Patch %	Lines
lightning/src/ln/channel.rs	92.98%	3 Missing and 1 partial ⚠️
lightning/src/util/test_channel_signer.rs	0.00%	1 Missing and 3 partials ⚠️
lightning/src/ln/channelmanager.rs	80.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3153      +/-   ##
==========================================
+ Coverage   89.78%   91.12%   +1.33%     
==========================================
  Files         123      126       +3     
  Lines      102330   114900   +12570     
  Branches   102330   114900   +12570     
==========================================
+ Hits        91876   104701   +12825     
+ Misses       7763     7708      -55     
+ Partials     2691     2491     -200     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[alecchendev]

rebased because of conflicts

[TheBlueMatt]

A few nits asking for more tests, but LGTM I think. @valentinewallace ?

[valentinewallace]

Taking a look!

[alecchendev]

rebased because of conflicts as well

[valentinewallace]

I'm good with a squash then landing this!

[TheBlueMatt]

Feel free to squash, lets get this over the line!

[alecchendev]

addressed latest nits and squashed

[TheBlueMatt]

Ugh, I think this is gonna cause issues - we currently assume that ShutdownComplete means a channel can't exist after its set and assert it a few other places. Currently, what if a user calls force_shutdown on a channel while its pending, I think we'll panic, but also in some message handlers we assert that the state is ChannelReady and could similarly panic after a peer sends us the wrong message. Instead, I think we should leave the channel as ChannelReady and just check the state in the shutdown messages (other things, IIRC, already check if the state has shutdown_sent).

[alecchendev]

Alright, made sure not the set ShutdownComplete in the pending signatures case, and added a helper to check whether we're basically shutdown but waiting on the signature, which is used in the check here + debug asserts, lmk if that works

[TheBlueMatt]

Thanks, feel free to squash.

[TheBlueMatt]

Sorry for the delay, release process is always fun. I think this LGTM.

[alecchendev]

squashed

[TheBlueMatt]

As a followup, can we simulate a reconnect here? We should make sure a disconnect/reconnect here doesn't cause failure to finish the closing signed dance.