Further improve unconfirmed tx conflict resolution

[evanlinjin]

Describe the enhancement

At the end of ticket #1063's description, there is a Further work section which states:

Our current structures do not handle unconfirmed conflicts properly when the conflicting transactions have the same last_seen timestamp (thanks to @rajarshimaitra for pointing this out).

bdk/crates/chain/tests/test_indexed_tx_graph.rs

Lines 692 to 695 in fe7bba1

	// FIXME: Currently both the mempool tx are indexed and listed out. This can happen in case of RBF fee bumps,
	// when both the txs are observed at a single sync time. This can be resolved by checking the input's nSequence.
	// Additionally in case of non RBF conflicts at same `seen_at`, conflicting txids can be reported back for filtering
	// out in higher layers. This is similar to what core rpc does in case of unresolvable conflicts.

I propose we deal with this as follows:

When two unconfirmed txs conflict, but have the same last_seen, we can check the input's sequences (using RBF rules). Otherwise, we sort by feerate (if possible). We fallback to lexicographical sorting of txids.

[LLFourn]

@evanlinjin I don't understand how do we fall back to checking the input's nsequence?

I would not use RBF flagging since it isn't even being enforced anymore by lots of miners: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021890.html

Check if one tx has a higher absolute fee and feerate and then choose that one. If they can't be distinguished using this rule then I would just report one arbitrarily. Reporting both transactions as conflicted sounds like it could be useful. I'm not sure how this would bubble up to filter_chain_unspents.

[evanlinjin]

@LLFourn I agree that we should just base it on fee/feerate only (so no nsequence).

The root of the problem would be in get_chain_position, which would bubble up to filter_chain_unspents, list_chain_txs, etc.