Do not record unilateral closes as payments

[tankyleo]

Unilateral closes are not onchain payments. The real on-chain credits to our onchain balance after a unilateral close happen on Sweep and Claim transactions.

Also, UnilateralClose payments currently never graduate from the Pending state, as no BDK events are emitted when these transactions confirm.

Co-Authored-By: HAL 9000

[ldk-reviews-bot]

👋 Thanks for assigning @jkczyz as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[tankyleo]

Continued from #660

The original motivation for this change: commitment transactions in 0FC channels have zero-fees and zero-amount according to BDK (since they don't interact with the on-chain wallet), so these were not recorded in the payment store. I then failed the assertion in the channel_full_cycle test that asserts that UnilateralClose was present in the payment store.

Hmm, these don't directly interact with the onchain wallet, but wouldn't it still make sense to record them as otherwise users would have a 'gap' between channel funding and the resulting Sweep transaction? If we keep them that could allow them to track the funds end-to-end, on each step?

Would have to think more about the overall purpose of payment store, as a user I think I would find it quite confusing for there to be a zero-amount inbound payment, with a non-zero fee. In the case of zero-fee commitment channels, these would be inbound payment for zero-amount, zero-fee (but the entry could still allow us to track the movement of funds).

Also note that currently UnilteralClose only gets recorded for outbound channels, as BDK can tracks the funding output and assigns a non-zero fee only in this case. This makes sense as for inbound channels, the fee of the commitment transaction comes from the counterparty's balance, not our balance.

[tnull]

Yeah, makes sense to me, though I still think it somehow would be nice to show users the intermediate transaction state somehow. But you're probably right that the payment store is not the right place to do it.

[tnull]

nit: Can we just reuse assert_all_nodes_have_onchain_tx_type and invert the predicate?