utxonursery: delete

[joostjager]

The on-chain sweeping sub-system 'utxo nursery' is now considered legacy code that needs to be phased out over time. Part of the functionality has already been ported to other sub-systems.

A sweeper sub-system was introduced to publish the chain transactions in #1960. This marked the beginning of the end of the nursery.

PR #2407 removed the nursery dependency for sweeps of direct commitment outputs for txes published by the remote party.

PR #3644 furthers this work by also bypassing nursery for locally published commitment txes.

This issue serves as a tracking issue for the remaining changes required:

• Claiming an htlc with the preimage on a locally published commit tx (htlcSuccessResolver): cnct: remove nursery dependency from success resolver #3977 .
• Timing out an htlc and reclaiming the funds (htlcTimeoutResolver)

When done, all code from UtxoNursery and NurseryStore can be removed from the code base.

[joostjager]

One potential complication of converting the last two resolvers to not use nursery anymore is that on upgrade there may be pending resolvers. Those resolvers may already have handed off sweeps to the nursery and those may then interfere with the new resolver code. Or there may be transactions in the mempool or in a block that originate from the nursery. These may not be expected by the new resolvers.

One way to address this is by combining all the following steps:

• Convert the remaining resolvers (htlcTimeoutResolver and htlcSuccessResolver) at the same time. That way, the nursery can be deleted completely and there is no chance of active interference of the nursery with the new style resolvers.
• Implement the new resolvers in a stateless way. Discard any persisted state and only rely on the chain to infer the current state.
• To prevent prior nursery sweep txes from not being recognized as our own, carry out a light 'migration' that inserts tx ids of nursery transactions into the sweeper's "our txes" set.

I think that with these steps, the switch over will be safe and also not too complicated to reason about.

[saubyk]

cc: @yyforyongyu is this issue relevant still?

[yyforyongyu]

yeah we still need to remove it, can be tracked as the last task in #8680

[saubyk]

Closing this issue as the ask is covered with the list of requirements in #8680