feat(ARCO-115): Reorg Support

[kuba-4chain]

Description of Changes

1. Processing of blocks received from peers was improved to allow for:
   • proper handling of ORPHANED blocks - updating them backwards with each new incoming block that extends the orphaned chain and publishing their transactions if they become part of the longest chain
   • secure handling of concurrent blocks being processed - by updating the UpsertBlock query with additional checks
2. Database method GetBlockGaps was updated and simplified.
3. The sum of chainworks of competing forks is now compared to find out the longest chain, instead of comparing the chainwork of only the tips of forks.
4. A great number of fixtures and unit tests were added to ensure maximum test coverage - as this is a rare scenario, difficult to spot and debug in production.
5. E2E tests were improved, by decreasing the fillGapsInterval to 1 second - to make sure there are no gaps when the tests begin.
6. A new transaction status MINED_IN_STALE_BLOCK was introduced in metamorph api.
7. The way of publishing mined transactions to metamorph was updated
   • transactions from incoming block, that's extending the longest chain, are published to metamorph as MINED - no change here
   • transactions from incoming block, that's extending a stale chain, that are not found in the longest chain are in SEEN_ON_NETWORK state (ignored) until they are found in the longest chain (which eventually should happen, because nodes put those transactions back in their mempool)
   • in case of reorg, transactions from the entire stale chain, that is now becoming the longest chain, are published
     • transactions that were previously found in the longest chain that is now becoming a stale chain are published with updated block data (block hash, block height and merkle path)
     • transactions that were not found in the longest chain are published as newly mined
   • in case of reorg, transactions from the previously longest chain that were NOT found in the new longest chain are published as MINED_IN_STALE_BLOCK - this is to inform users that their transaction is no longer mined in the longest chain, so they have to wait until it's MINED again
8. An integration test for the entire reorg process, including updating transactions, was written, covering all of the above-mentioned scenarios and some more edge cases - for single-instance processing.
9. Small refactor of structures
   • PeerTxMessage -> TxStatusMessage
   • GetMinedTransactionsResult -> TransactionBlock
   • New structure chain -> slice of blocks

Flow diagram of the updated processBlock function in blocktx processor

Linked Issues / Tickets

ARCO-178
ARCO-179
ARCO-199

Testing Procedure

Describe the tests you've added or any testing steps you've taken.

• I have added new unit tests
• All tests pass locally
• I have tested manually in my local environment

Checklist:

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have updated CHANGELOG.md with my changes

[sonarqubecloud]

Quality Gate failed

Failed conditions
79.8% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud