Exchanges logging and database updates

[Lezek123]

This PR implements adding logs of burning transactions to the databse based on the chain subscription. Each transaction log consists of:

• sender (address)
• recipient (address)
• senderMemo (at the moment of transaction)
• amount (of tokens sent)
• fees
• date (of the transaction)
• blockHeight (of the transaction)
• price (of one token at the moment of transaction)

It also updates tokensBurned and sizeDollarPool after each processed block.

Important things to note:

• There is a mechanism which prevents processing block x before block x-1 is processed to prevent the possibility of using outdated sizeDollarPool etc. (since blocks are processed asnychronously)
• This check is skipped for the first block beeing processed after the script is run (so it can be run succesfully with outdated or no value in lastBlockProcessed field in the database)
• I think we should be only processing finalized blocks, that's why I changed api.query.system.events subscription to api.rpc.chain.subscribeFinalizedHeads, which also gives us some useful data like block hash, block number, parent hash etc., which we can then use to fetch the data we need using .at()

[Lezek123]

I refactored transfers.ts in order to make the server more failproof and be able to recover after critical errors, loss of power etc.

The flow should be like this:

1. When recieving new block head from subscription, if there are some blocks missing between lastBlockProcessed and the new block - try to process missing blocks first (by querying api.rpc.chain.getBlockHash(blockNumber) and api.rpc.chain.getBlock(blockHash))
2. There is a lock that prevents multiple blocks from beeing processed simountinously. Along with other implemented mechanisms it should prevent processing same block twice or processing blocks before their parent is processed. When the block that is requested to be processed is <= lastProcessedBlock - the processing is skipped.
3. If proccessing a block takes too much time (which is specified by BLOCK_PROCESSING_TIMEOUT) and the lock cannot be released or some other critical error occurs during the processing - this event will be logged into the database, the lastProcessedBlock will be updated to the faulty block number (to prevent trying to proccess it again) and the process will exit, allowing safe restart (which can be implemented with tools like forever).

The most noticable change is that now the server can "break" at any point for any time and it should be able to recover from such situation and process all the remainig blocks between lastBlockProcessed and current block when the script is re-run. It should also be able to handle a situation when subscription is not working as expected and is not providing us all the headers or providing them in a wrong order or some of the blocks cannot be processed for some reason.

[bwhm]

7