Fixes #11

[Coretaker101]

Fixes #11

---

Requires re-index? == No

Affects API interface AND/OR response data format? == No

---

Explanation:

TxHistoryRow is just a key in rocksdb. Which means it is encoding all its information into the key and (most likely intentionally) using the property that inserting the same key twice will de-duplicate to its advantage.

In the case where txA is confirmed in orphaned block at height 10, returned to our mempool, then confirmed in new-best-chain block 15 etc. The keys are not the same (since the key contains the block height).

Other endpoints use unique() on txid etc. so there shouldn't be any problems with the other endpoints... However, this can't be properly fixed without a re-working of the index (which will require a re-index of esplora)

For now, we avoid unique() since it would just give the same result, and instead use unique_by and return a tuple of the txid + the outpoint (for spends it's the previous outpoint, for funds it's this txid+this output index. If we don't include the txid(), then it would remove the spend of each fund->spend pair)

Note: utxo_delta does not have the same problem because it uses a HashMap with the Outpoint as the key to accumulate the results, removing any duplicates.

Originally posted by @junderw in mempool/electrs#12