Mitigate issues in the migration to "block_hash" indexing approach

[vbaranov]

Motivation

In migration to block_hash indexing approach we should clear the DB from possible inconsistencies (cc #2699 #2697 #2695)

Changelog

1. Before constructing primary key on all tables we should check that there are no rows with empty block_hash
2. We should check for possible duplicates of a pair [block_hash, block_index] before creating a primary key on them on internal_transactions table.
3. Looks like, create(index(:logs, [:block_number])) index is unused in the new approach.

Checklist for your Pull Request (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 by submitting a PR to https://github.com/blockscout/docs
• If I added/changed/removed ENV var, I submitted a PR to https://github.com/blockscout/docs to update the list of env vars at https://github.com/blockscout/docs/blob/master/for-developers/information-and-settings/env-variables.md and I updated the version to master in the Version column. Changes will be reflected in this table: https://docs.blockscout.com/for-developers/information-and-settings/env-variables.
• If I add new indices into DB, I checked, that they are not redundant with PGHero or other tools

[coveralls]

Pull Request Test Coverage Report for Build ab2fa284-ea11-4e75-a99e-3b891971d843

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 75.44%

---

Totals
Change from base Build 40db3a00-b82e-4dfe-90f8-b3b8b7d7679a:	0.0%
Covered Lines:	5311
Relevant Lines:	7040

---

💛 - Coveralls