Stale block address indexing bug

[mononaut]

Electrs appears to double-count certain transactions during address indexing, which produces incorrect chain stats (funded_txo_sum etc) and therefore incorrect balances displayed on mempool.space.

---

Specifically, the error seems to occur when a transaction is included in a stale block, but not the "winning" block at the same height.

For example, transaction 3738...e88e
was included in a recent stale block 000000000000000000032956cbfd8721abe0572d81542e75e38e6185312bee09 at height 792379, but eventually entered the main chain in block 792380.

The transaction is then double-counted during address indexing,
causing address 132kFhZzkFytWAefWy7nCYgJHcU84RjJNa
to show a negative balance.

Similarly, transaction 3264...d9cb appears in the same stale block, enters the main chain in block 792382, and is counted twice towards address bc1qzuupxjkwv4dj69m3xzack5sdqtacn6l8czndlf, causing a positive balance to display when in fact the address should be empty.

---

Transactions which appear at the same height on both sides of a chain split appear to be handled correctly.

For example, address bc1pfajpg0fp0a62wjrax682hkzvrczxx7j3htrtm0ae6cnx72ye2rnscarxrp has a transaction which is included in both versions of block 792379, but reports the correct balance.

[mononaut]

As seen in mempool/mempool#4196, this still seems to be reproducing in production on multiple servers in all sites, e.g.

https://node203.fra.mempool.space/address/38A4VFuFs95QaxTPUec9jEVqW5rFE7z7jx
https://node204.tk7.mempool.space/address/38A4VFuFs95QaxTPUec9jEVqW5rFE7z7jx
https://node202.fmt.mempool.space/address/38A4VFuFs95QaxTPUec9jEVqW5rFE7z7jx

In this case transaction 20f7...3e8c was included in that same stale block at height 792379, and again in the main chain in block 792380, and so counted twice towards the address totals.

[junderw]

The solution is #28

Which I'm currently working on.