Persist counterparty_claimable_outpoints out of channel_monitor

[G8XSU]

Problem: After every commitment signed, counterparty_claimable_outpoints keeps on growing without bounds within a channel_monitor, with a new hashmap entry for each commitment_tx.

It poses two problems mainly:

Increased memory footprint, since all the active channel_monitors are stored in-memory.
Increased channel_monitor on-disk size, where these are currently stored.

We don't want to keep on storing outpoints which will only be used for revoked_tx / funding_spend, instead we would like to store them in cold storage and read them only when required.

Ideal outcome: After doing this, Ldk's memory footprint should be drastically decreased owing to removed in-memory hashmap entries of counterparty_claimable_outpoints

as part of #3049.

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 94.51477% with 13 lines in your changes missing coverage. Please review.

Project coverage is 89.83%. Comparing base (b706480) to head (4819a2a).

Files with missing lines	Patch %	Lines
lightning/src/chain/channelmonitor.rs	94.20%	3 Missing and 1 partial :warning:
lightning/src/events/mod.rs	84.21%	0 Missing and 3 partials :warning:
lightning/src/chain/chainmonitor.rs	91.30%	2 Missing :warning:
lightning/src/ln/functional_test_utils.rs	91.66%	1 Missing and 1 partial :warning:
lightning/src/ln/functional_tests.rs	98.85%	1 Missing :warning:
lightning/src/ln/monitor_tests.rs	66.66%	0 Missing and 1 partial :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3106      +/-   ##
==========================================
- Coverage   89.83%   89.83%   -0.01%     
==========================================
  Files         126      126              
  Lines      103107   103323     +216     
  Branches   103107   103323     +216     
==========================================
+ Hits        92629    92819     +190     
- Misses       7763     7780      +17     
- Partials     2715     2724       +9     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[TheBlueMatt]

I think we're still missing handling of HTLC spends on counterparty commitments. transactions_confirmed calls check_spend_holder_transaction but also checks if a transaction spends an input which is in counterparty_commitment_txn_on_chain and calls check_spend_counterparty_htlc in response. We'll need to do....something here. I think we'll want to store the txids of commitment transactions we're waiting on (unclear if we should do it in counterparty_commitment_txn_on_chain or not...needs some digging) somewhere and then store transactions that spend them in some pending queue to re-process once we get the data we need.

[G8XSU]

Had offline discussion with Matt on same. The case being discussed is here: https://github.com/lightningdevkit/rust-lightning/blob/main/lightning/src/chain/channelmonitor.rs#L4005

1. We will need to somehow store txs for which we are waiting on ClaimInfo.
2. We will need to somehow store full incoming tx detail for txs which spend commitment_tx in channel_monitor.

After this we have to execute this part of logic again: https://github.com/lightningdevkit/rust-lightning/blob/main/lightning/src/chain/channelmonitor.rs#L3999-L4023

---

Also, earlier there was a question regarding panic on ClaimInfoNotFound, but it is a genuine use-case in case of coop close.

• We need to add a testcase for co-op close, where we get the ClaimInfoRequest, but don't provide ClaimInfo to LDK.

[G8XSU]

• Added a testcase for coop close to verify that we generate ClaimInfoRequest But it didn't verify the expected behavior, this is because in case of coop close, we don't broadcast commitment tx. So this is expected, not going to add it to this PR.

[TheBlueMatt]

We could do it in a followup (ideally in the same release), but we should encrypt these objects with the single-hash of the commitment transaction - that means this data isn't itself sufficient to see HTLC forwarding history.