[Splicing] Signer extended with method to sign prev funding transaction input

[optout21]

Fixes #3312 . (#1621 )

New method to sign an input of a transaction with our funding key.
Used for splicing, when signing the previous funding transaction. The previous funding transaction becomes an input to the new funding transaction, and it is a multisig, which we also need to sign.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 26 lines in your changes missing coverage. Please review.

Project coverage is 89.56%. Comparing base (0db051b) to head (f22b011).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/sign/mod.rs	0.00%	20 Missing ⚠️
lightning/src/util/test_channel_signer.rs	0.00%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3316      +/-   ##
==========================================
- Coverage   89.61%   89.56%   -0.05%     
==========================================
  Files         127      127              
  Lines      103534   103560      +26     
  Branches   103534   103560      +26     
==========================================
- Hits        92781    92756      -25     
- Misses       8053     8101      +48     
- Partials     2700     2703       +3     

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

[TheBlueMatt]

The input_redeem_script, input_index, and input_value should all be redundant, right? The InMemorySigner should know the channel value and funding outpoint.

[optout21]

Hm, I haven't thought about that.
The redeem script can be derived by the signer as well, true (funding pubkeys don't change).
The input_index is the index of the prev funding in the new funding (splicing) transaction, that's outside of the signer's scope.
The previous channel value could be used from the signer, unless already updated! The signing happens after the initial negotiation handshake, and in the current proto implementation (not set in stone) by that time the signer is already updated to the new channel value. However, I would keep this as a parameter, as it's more general, not to limit the space of possible implementations. (Another option would be to keep the whole previous signer.)
In conclusion, I remove the script parameter, but keep the value and index parameters.

[TheBlueMatt]

Doesn't the signer need to keep track of all previous funding values anyway, since it has to sign for multiple commitment transactions on both sides of the splice until the splice confirms?

[TheBlueMatt]

Mmm, I guess to keep our implementation simple we'd have to have some scheme like the CommitmentTransaction's trust method that gives access to "trusted" data. I guess I'm fine with leaving it.

[TheBlueMatt]

LGTM modulo doc clarification.

[optout21]

Documentation updated per the suggestions

[jkczyz]

LGTM modulo one small change

[optout21]

LGTM modulo one small change

Changed (also rebased)