Implement functionality for removing blocks stored in temp table

[michielmulders]

Expected behavior

Should be able to remove blocks stored in temp table and implement a check to see if the table is present/holds records.

Which version(s) does this affect? (Environment, OS, etc...)

feature/improve-bft

[sridharmeganathan]

@michielmulders will do the analysis before the next sprint grooming meeting.

[michielmulders]

Discussion Conclusion

Both option 1 and 2 were preferred so the meeting ended with voting.
Option one was the preferred option and won with 6 votes to 2.

Meeting notes

Three options:

1. DB
2. File
3. No temp - Trust on the resiliency of application -> not following the LIP and dangerous --> Excluded
4. Atomic operation: First get all blocks, and only commit when we are up to the height and sure to commit. If it crashes, the same operation starts again.

When writing to DB, you have the benefit of using rollback/commit.
For writing to file, we have to write code to check if the file write operation has succeeded.

For FCS, it makes more sense to use quick file storage as only 202 blocks at max will be written. For BSM, potentially much more blocks will be written to a temp file, DB makes more sense here.

Finalization after 160+- blocks, no impact on BSM.
Dangerous to not store blocks, what if nobody can provide the block you need, you will have to violate protocol rules. You'll have to check upon start before forging that you have the latest height?

For the sake of consistency, we should opt for a temp table for blocks and txs.
We have logic that returns block data as JSON and logic that can again process this JSON to be stored in the DB. Can be useful for writing to file: DB (JSON) -> File (JSON) -> crash? -> process JSON -> DB (JSON).

Counter-argument: Everything related to blockchain is persisted to Postgres, everything not related/non-persistent is stored outside.

---

On startup, check if tables are empty - what to do if data is present in temp storage?