Data obtained from the database was not properly handled in some cases:
- If some appointments are accepted and no block is received and the tower is restarted, the data was not loaded. The tower was checking that the Watcher/Responder had a last known block, which may not have been the case. Now best_tip is set as last_known_block on a fresh bootstrap.
- The Watcher/ Responder were not being awaken when loading data from the database.
- The block queues were not properly populated
- The builder was never modified when the in-memory data was reduced, so it was still trying to build data based on the past approach.
- Renames create_block_queue to poplate_block_queue and repurposes the method
When creating a block queue, a new Queue was created and populated. That was breaking the link between the Watcher/Responder and the ChainMonitor since the Queue is defined beforehand.
Logger was only used to log when a new folder was created, and was making that the setup needed to be done on the main of pisad and cli instead of __init__, which seems a better fit
The setup of the logs and the parsing of the config file are closely related. The former need info from the later to be created, and needs to be setup only once
per pisa instance. In the same way, the later need to only be loaded and validated once per pisa intance and contains info to setup the logs.
Intead of setting up the logs in init and loading the config file in pisad, now both are dealt with in __init__
When an appointment was triggered a flag was set in the Watcher, and removed later on in the Responder if the transaction ended up being rejected. That's pretty annoying. Since we have information about whether a transaction has made it to the mempool or not via the Carrier's receipt, this can be all done in the Watcher, which makes more sense and reduces the interaction with the db (1 write if succeeds, 0 otherwise instead of 1 write if succeeds, 2 otherwise).
- Refactors store_update_locator_map name to create_append_locator_map, which is a better fit.
- Adds update_locator_map method to update maps by removing some uuids (store_update_locator_map was not covering this, what was misleading).
- Adds missing docs.
- Improves code modularity.
- Separates flag_triggered from delete_appointment, which was pretty misleading (and causing some minor bugs) and make them work with lists intead of single objects.
- Removes unused import
The appointment endpoint was a parameter even though the method is only used to send data the a single endpoint. The json data is only used inside the method, so it can be computed there too.
