Preserve evicted outgoing transactions in wallet to prevent duplicate payment risk

[evanlinjin]

We should ensure correct behavior in the following scenarios

Scenario 1: Outgoing transaction is evicted from the mempool due to insufficient fees.

• Current behavior (master): The transaction disappears from the wallet’s transaction list.
• Risk with current behavior: The caller may create another outgoing transaction, and the coin selection algorithm may choose outputs that can coexist in the same
  subgraph as the original transaction. This can result in an accidental double payment if the original transaction later reappears in the mempool or gets confirmed.
• Ideal behavior: The transaction remains in the wallet’s transaction list. We can see that it is uncanonical and does not conflict with any canonical transactions.
  The caller can then choose to fee-bump or cancel it.

Scenario 2: Outgoing transaction is evicted from the mempool because its parent (an incoming transaction) was cancelled.

• Current behavior (master): The transaction disappears from the wallet’s transaction list.
• Risk with current behavior: Same risk as in Scenario 1.
• Ideal behavior: The transaction remains in the wallet’s transaction list. We can see that one of its inputs conflicts with the cancellation transaction.
  • If the transaction has only this one input, the caller should have the option to wait until the conflicting cancellation transaction reaches a chosen confirmation
    threshold before forgetting the original transaction.
  • If the transaction has multiple inputs, the caller should have the option to replace or cancel it.
• Additional notes: Spending from unconfirmed incoming transactions should be discouraged to avoid this scenario. There should be an option allowing the caller to set
  a minimum confirmation count before an incoming transaction becomes eligible for spending.

Scenario 3: A chain reorg unconfirms a previously confirmed transaction, and it is not re-introduced to the mempool.

• Current behavior (master): The transaction can vanish from view, alongside it's descendants.
• Risk with current behavior: The caller may create a duplicate or conflicting payments for itself and all of it's descendants.
• Ideal behavior: The transaction and descendants remain in the wallet's transaction list. The caller can check whether these newly-uncanonical transactions has conflicts and whether those conflicts are confirmed or not. Can we somehow merge/replace the whole package?

TODO: More scenarios

Notes on RBF

In bdk_wallet::Wallet, the current RBF implementation reuses all inputs from the original transaction.
This guarantees that any subsequent RBF cannot be part of the same subgraph as the original transaction or its earlier replacements, reducing the risk of accidental duplicate payments. This is also the behavior in Bitcoin Core.

We should incentivize this behavior for now.

[notmandatory]

@evanlinjin can we move this to the 3.0 milestone since #257 is still a draft?

[evanlinjin]

@notmandatory yes, I'm not sure why this was ever in 2.2