Refactor block_store.rs

[shawn-zil]

This was observed while working on issue #1878

The BlockRequest mechanism seems to be broken somewhere as the blocks are being requested, serviced and cached.

2024-12-19T07:03:22.466175Z TRACE zilliqa::block_store: 684: block_store:: buffer_proposal 72, hc 0
2024-12-19T07:03:22.466233Z TRACE zilliqa::block_store: 684: block_store:: buffer_proposal 73, hc 0
2024-12-19T07:03:22.466280Z TRACE zilliqa::block_store: 684: block_store:: buffer_proposal 74, hc 0
2024-12-19T07:03:22.466347Z TRACE zilliqa::node: 945: block_store::handle_block_response: finished handling response
2024-12-19T07:03:22.613869Z TRACE zilliqa::block_store: 680: block_store:: new highest known view view=75
2024-12-19T07:03:22.613874Z TRACE zilliqa::block_store: 684: block_store:: buffer_proposal 75, hc 0

However, they don't seem to be written to disk for some reason:

SQLite version 3.45.1 2024-01-30 16:01:20
Enter ".help" for usage hints.
sqlite> select count(*) from blocks;
1

So the node just keeps on caching and caching.

This will necessitate a little more investigation.

[shawn-zil]

Repurposing this issue for the block_store.rs refactor.

[shawn-zil]

1. Make peers unique, or equal - check when adding new peers. Otherwise, it risks having a single source of truth i.e. alternating between one peer and it's duplicate.
2. Save metadata in DB to allow restarts? No. Which would allow any broken chains to be simply handled by restarting the sync process. Otherwise, we need to automate restarts.
3. Since P1 is I/O bound, fire off more requests? Danger is gaps in V1 views. So, drift would have to be large and may limit the effectiveness of this technique.
4. Cache V1 responses?