[bug]: sweep: BumpFee can cause transaction conflicts

[morehouse]

UtxoSweeper.UpdateParams updates the parameters for a specified input and resets its state to Init, after which the sweeper can create a new transaction for the input. But UpdateParams does not cancel any existing fee bumps for the input.

Thus, we can end up with the fee bumper creating multiple conflicting transactions each block. The fee bumper will not notice the conflicting transactions until one of them confirms, at which point any unspent inputs are allowed to be batched again.

These rebatched inputs will not be swept for at least 1 block after the conflicting transaction confirms, potentially causing deadlines to be missed in some edge cases.

Example edge case

1. Inputs A, B, C all have a deadline in 6 blocks and are batched into a single transaction Tx1.
2. After 4 blocks, Tx1 still hasn't confirmed. The user increases the budget for input A using BumpFee. The sweeper creates a new transaction Tx2 containing only input A.
3. In the 5th block, Tx2 confirms. Inputs A and C are rebatched into a new transaction Tx3.

Tx3 now cannot confirm before the deadline.

Solution

UpdateParams should probably cancel any existing fee bump for the specified input. This would allow immediate rebatching of inputs in the original transaction using the updated parameters.

[yyforyongyu]

There's a related issue #8736, that we think when bumping the fees of a given input, if it's already in a set, we would instead bump the whole set to avoid fee bumping races. In addition, there's a TODO in #8680 which aids this new behavior,

update PendingSweeps to return inputs in InputSet, which gives users more info about the sweeping tx, so better decisions can be made when calling BumpFee.