Updates handle_reorg to work with the current version of the Responder (the old code was outdated and broken).
`check_tx_in_chain` was only used by `handle_reorgs`, and made not much sense at this point. The method need to check if the transaction is in mempool or blockchain, so it seems to make more sense bulding on top of `get_transaction`.
Transactions were included in the mempool as rawtxs but checked as txids, so effectively every time we checked if a transaction was in mempool it returned false
Excluding the basic reorgs hangle, we need a better bitcoind mock or a different testing approach to reach a higher code coverage. This is as far as it can get for the Responder at the moment
There were a couple of wrong things going on in the `Responder`:
- `check_confirmations` included in 8a10979db0 was not doing a good job keeping track of the missed confirmations, probably due to a overlooked refactor.
- There was an edge case when adding txs to `unconfirmed_txs` on `create_job` that may lead to a transaction being confirmed and unconfirmed at the same time from the `Responder's` pow. It could be triggered by adding two jobs with the same justice_txid.
Brings back check_potential_matches and check_matches to the Watcher.
The methods have now been renamed to check_matches (old check_potential_matches) and filter_valid_matches (old check_matches) to provide a better description of their purpose.
decode_raw_transaction has been added to BlockProcessor
After adding the triggered flag we can not just use to_json to serialize since the two data blobs won't match. This also sets ground towards having a generalized serialization function.
In order to use the db for system monitoring we need a way of mapping the locator the the uuids the appointments/jobs are identified in the db. First steps towards #15
