Handle fallible per commitment point in channel establishment

[alecchendev]

Builds on #3086, #3096, #3115. First PR to handle fallible get_per_commitment_point signer method.

We make get_per_commitment_point return a result type so that in the Err case, we (LDK) can resume operation while an async signer fetches the commitment point. This will typically block sending out a message, but otherwise most state updates will occur. When the signature arrives, the user is expected to call ChannelManager::signer_unblocked and we will retry get_per_commitment_point however this time the signer will return the commitment point with Ok, and we'll send out our message.

This PR implements this flow for channel establishment, i.e. open_channel, accept_channel, and channel_ready.

Rough outline of how our HolderCommitmentPoint advances and gets new signatures:

• sending open_channel - creates new outbound channel, immediately requests the first commit point, waits to have the first 2 commit points to be unblocked to send the message
• sending accept_channel - same ^
• sending funding_created - no op regarding commit points
• receiving funding_created - uses point to verify first commitment, then advances commitment, requesting next point
• sending funding_signed - no op
• receiving funding_signed - same as above, verifies, advances, requests next point
• sending channel_ready - waits to have the next commit point ready, then once unblocked sends the current point in the channel_ready message

To do

• Implement sending channel_ready upon the signer being unblocked
• test channel_ready
  • already tested in the funding_signed tests
• Fix couple post merge comments from Add HolderCommitmentPoint struct to track commitment points #3086

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 70.88123% with 76 lines in your changes missing coverage. Please review.

Project coverage is 89.78%. Comparing base (f2237a7) to head (744f2ca).

Files	Patch %	Lines
lightning/src/util/test_channel_signer.rs	36.53%	33 Missing ⚠️
lightning/src/ln/channel.rs	80.37%	29 Missing and 2 partials ⚠️
lightning/src/ln/functional_test_utils.rs	0.00%	6 Missing ⚠️
lightning/src/ln/channelmanager.rs	87.87%	0 Missing and 4 partials ⚠️
lightning/src/util/test_utils.rs	50.00%	0 Missing and 2 partials ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3109      +/-   ##
==========================================
- Coverage   89.79%   89.78%   -0.02%     
==========================================
  Files         119      119              
  Lines       97884    97966      +82     
  Branches    97884    97966      +82     
==========================================
+ Hits        87894    87955      +61     
- Misses       7415     7435      +20     
- Partials     2575     2576       +1     

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

[alecchendev]

the commits from #3115 are second from the end, will rebase on top later this week, but generally most of the stuff here is in place

[TheBlueMatt]

Actually, looking at this again this API is super weird - advance may reduce the commitment transaction number by one....or it may not. ISTM the callsites mostly want it to actually advance, and are wrong in cases where we're PendingNext or otherwise don't advance here. Should this return a Result?

[alecchendev]

there's the callsites 1. in funding_created/signed + commitment update where it wants to advance and is expected to be Available and go to PendingNext and then there are the callsites 2. in signer_unblocked where we call advance to try to go from PendingNext to Available if the signer has the commitment point. Not sure how to best enforce this. Maybe should these be two separate functions to distinguish what we're trying to do at each of these?

if advance returned Result, what would be an example of how we'd want to handle the err case at a callsite?

[TheBlueMatt]

Not sure about this PR, but in git HEAD (after the previous PR was merged) all callsites currently want to move to the next point. The current code always first sees that we're Available, then sets us to PendingNext with the number one lower, then also checks and sees that we're now PendingNext (cause we just set it), and sets us to Available at the same number. Thus, the net result of the method today is we always transition from Available to Available with a tx number one lower and the correct points.

[alecchendev]

split into different functions, advance and try_resolve_pending (not sure if its the best name), and made advance return a Result and just defaulted to returning a closing error if we failed to advance the commitment number.

[TheBlueMatt]

I thought we were going to first handle all the async cases post-funding and then add support for handling the async case during initial channel bring up in a separate PR?