Improve speed of nonconsensus data removal

[pasqu4le]

Motivation

The recently introduction of non-consensus block's data removal is not efficient enough to keep the pace with block creation.

Changelog

Enhancements

This PR changes the logic to remove only data of blocks that lose consensus because they are being overridden (as opposed to also for blocks that are invalid neighbors) and changes the queries to perform.

Checklist for your PR

• I added an entry to CHANGELOG.md with this PR
• If I added new functionality, I added tests covering it.
• If I fixed a bug, I added a regression test to prevent the bug from silently reappearing again.
• I checked whether I should update the docs and did so if necessary
• If I added/changed/removed ENV var, I should update the list of env vars in https://github.com/poanetwork/blockscout/blob/master/docs/env-variables.md to reflect changes in the table here https://poanetwork.github.io/blockscout/#/env-variables?id=blockscout-env-variables. I've set master in the Version column.
• If I add new indices into DB, I checked, that they don't redundant with PGHero or other tools

[coveralls]

Pull Request Test Coverage Report for Build 16282840-fb5b-4d95-9aba-e9af732f0d66

• 18 of 22 (81.82%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.03%) to 78.506%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
apps/explorer/lib/explorer/chain/import/runner/blocks.ex	18	22	81.82%

Totals
Change from base Build d94c369a-8b26-40e5-96e1-4626be9542eb:	-0.03%
Covered Lines:	5245
Relevant Lines:	6681

---

💛 - Coveralls

[ayrat555]

PR's description says

This PR changes the logic to remove only data of blocks that lose consensus because they are being overridden (as opposed to also for blocks that are invalid **neighbors**)

it looks like it also removes data from invalid neighbours because they are selected with where_invalid_neighbour(changes_list)

I see optimisation in using block_hash'es for selecting transactions instread of using block_number's because we have DB index for block_hash in the transactions table

[pasqu4le]

@ayrat555 yes the invalid neighbors blocks are still removed, however if you look at each remove_nonconsensus_xxx step you'll find that now they take transaction hashes from the result of derive_transaction_forks, in other terms all the hashes of the transactions that have been forked.

What I figured was in fact that we do not fork transactions for invalid neighbors because those will be handled after anyway (neighbor loses consensus > get refetched > new block is inserted and old transactions get forked) and we can do the same for the rest of the nonconsensus data.