refactor(database, state-indexer): State schema improvements for reads and updates

[khorolets]

This PR is a continuation of @kobayurii work done in #394 that we have rejected because we could not write (index) the data fast enough to support that idea.

After a bunch of different experiments and other ideas for improving the schema we got back to that schema and optimized it enough to increase a throughput on our side to be able to index the tip of the network or backfill.

TL;DR

Average blocks per second:

• Before: 0.1 BPS
• After: 5.0-12.0 BPS

Key changes:

• state_changes_{family} tables have to be converted into state_changes_{family}_compact:
  • block_height changes to block_height_from representing the moment in time when the particular record becomes "active"
  • new field block_height_to together with the block_height_from builds up a range of "active" period for a particular record
  • Altogether this allows to dramatically shrink the lookup range for PostgreSQL thus increasing the speed or reads for all the state changes related data in ReadRPC (state, access keys, account, contract)
• Inserts and updates (introduced logic to support block_height_to) are refactored to be done in parallel on per partition basis.
  • A function get_text_partition on the PostgreSQL side that allows to map account_id to the partition is added
• And a cherry on top: we need to migrate block_height_from and block_height_to column types from numeric(20, 0) to bigint. Correspondingly, they represent u64 and i64. And while block height is u64 (the reason we used numeric(20, 0)) we still can fit it in i64 for a long time from now. The bigint field is much more performant on the PostgreSQL side for our inserts and updates.

NB! Before releasing this we need to fix/update migrations to ensure we create the proper schema. Also we need to migrate our entire databases for a new schema.

[kobayurii]

Grate! Thank you!