ARCO-142: add competing txs to broadcast response

[pawellewandowski98]

Description of Changes

Added competingTxs to BroadcastResponse, they are sent if double spend was attempted.

Linked Issues / Tickets

ARCO-142

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
• [x] I have tested manually in my local environment

Checklist:

• [x] 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
• [ ] I have run npm run doc and npm run lint one final time before requesting a review
• [ ] I have run npm version patch so that my changes will trigger a new version to be released when they are merged

[ty-everett]

Isn't this a BroadcastFailure?

[kuba-4chain]

It is not, at least not in the way Arc processes transactions. Arc accepts that transaction and keeps track of it, because nodes may accept that transaction into mempool and Arc wants to see which one of the competing transactions will ultimately become MINED and which one(s) will become REJECTED and update the status accordingly.

In most cases, it will obviously be the one seen first by the nodes, but in case two transactions (spending the same UTXO) get accepted by different nodes at exactly the same time, it's up to the nodes to decide.

A broadcast error happens when there is something wrong with the transaction (or broadcast) itself and the nodes will not accept it.