feat: use id_indexed_v1 store for history network

[morph-dev]

What was wrong?

The history storage still uses LegacyHistoryStore. This will migrate it to IdIndexedV1Store.

How was it fixed?

Change to the IdIndexedV1Store implementation.

On the startup, this will perform the migration which can take few minutes (depending on the db size):

• rename table
• drop old indices
• create new indices

Remaining tasks for future PR-s:

• Delete LegacyHistoryStore and related code, but leave migration code
• Delete migration code

To-Do

• [x] Clean up commit history and use conventional commits.

[morph-dev]

I'm was waiting with merging until we observe some metrics while running this on some machines. Here are the observations, from 35GB (trin-nyc1-11) and 10GB (kolby-nyc1-5) databases:

• migrating to new store took 2h20min on 35GB and 20min on 10GB db
  • we have to recreate 2 indices, and that's what takes so long
  • :warning: When we release, we shouldn't upgrade all nodes at the same time, but we can do 5-10% of the nodes at the time
    • this will make release much longer, maybe 2-3 days
• :green_heart: it gives improvements in metrics in long term
  • insert+pruning:
    • 35GB: ~60ms old vs ~40ms new
    • 10GB : ~20ms old vs ~11ms new

• however, single pruning takes 0.5-1 sec in most of the cases on 35GB (0.1-0.3 sec on 10GB) and sometimes (rarely) even longer

  • :warning: this can be an issue as everything is blocked during this period (no other db reads or writes)
  • :bulb: we can reduce to prune only 50 entries at the time
    • maybe in future refactoring we can make this dynamic, something like:
    • If pruning takes less than 100ms increase number of entries to prune by 20%, if it takes more than 300ms, reduce it by 20%
    • where 100/300 ms is whatever we find reasonable

  Let's discuss this in today's meeting.