Don't double spend created transaction just because they haven't been broadcasted

[LLFourn]

This was a comment from a discussion elsewhere. I don't want to restrict the design space too much but I personally think the right way to deal with this is:

1. Insert the transactions into the tx graph right after they are created (without signatures)
2. Mark the txid as "unbroadcasted" at the tx graph level or application level
3. Assume it's canonical whenever you do canonicalization
4. Once it's signed, add the signatures to the tx graph. This can be done by re-inserting the transaction and adding it to the changeset with the new signatures.
5. When it gets a last_seen remove it from the unbraodcasted state.

I think in (2) it probably should be done inside the tx graph. #130 should be done first.

---

The user has to decide the fate of their transactions. And I claim each unconfirmed tx is either in a state of:

1. The user has not broadcasted it (maybe it's still being signed) and wants to confirm it eventually
2. It's broadcasted and the user still wants it to be confirmed
3. It's broadcasted but the user wants to replace it
4. It's not broadcasted and the user no longer wants to broadcast it.

We have to consider the state when creating a new tx: in (1,2) we want to treat the tx as canonical regardless of whether it has been seen in the mempool recently or not and therefore it's UTXOs can be candidate inputs. In (2), if it hasn't been seen for a while this will mean we want the user to broadcast it again along with the new child tx.
In state (3) the application has to treat it as non-canonical and double spend it with the replacing tx. In state (4) it's just non-canonical and remains that way.

I don't think there is a fifth state we have to model where the user is thinking "I broadcasted this tx but you know I don't really care if it gets confirmed. If it hasn't been seen for a while I kinda want to prune it so I might inadvertently double spend it with my next tx...or I might not..whatever".

There are several ways in which these four tx states are not modeled correctly in BDK so there definitely is a design bug but it seems we are not in agreement to the nature of it. I think states (2) and (4) are easy to express, YMWV with (3) and (1) doesn't exist.

Originally posted by @LLFourn in bitcoindevkit/bdk#1666 (comment)