feat: new BlockWriter implementation for block-as-file

[AlfredoG87]

Story

AS A Block Node Operator
I WANT to reduce the number of system calls needed to persist a single block
SO THAT I can minimize operating costs.

This task is to change block persistence to persist the blocks as whole files rather than directories of files per item (BlockAsDirWriter).

Tech Notes:

• Utilize the directory structure from Design a directory structure #125. Blocks will have a number (long) which will be also the block file's name. The trie we will have to facilitate these files will be a single digit per dir (node) for a depth of 18 (second to last possible digit
  position for a long, which has 19 digits) and the final digit will be part of the block file's name.

• For this issue's scope we will only need to support writing the block files to disk and we can disregard the rest of the notes of Design a directory structure #125 which will be part of subsequent issues, thus being said, we are mainly interested in:

  • When writing, initially we only care to write a new block file to the fs in the correct place, based on it's block number.
  • When writing a new block file, we need to check if the path to the file we want to write already exists, if it does, there is some problem, we should handle this case directly in our service.
  • When writing, we need to make sure that we will be making available the needed path for the trie ad hoc.

• Currently we have a interface BlockWriter<V> that is writing block items as files inside a directory with the number of the block, this causes multiple (potentially) thousands of system calls per block, slowing down the whole system (does it? Are system calls actually expensive or are we just assuming they are?).

• Current and only implementation BlockAsDirWriter was meant to support development and help on debugging by making it easy to see the block items as they are arriving, however due to the high TPS needed for the system, we want to create an additional BlockAsFileWriter implementation of BlockWriter<List<BlockItem>> to provide more performant support for production purposes.

• Some notes on permissions:

  • Do not pre-emptively attempt to fix file permissions. (this only creates more system calls that are completely not needed), instead if there is a IO issue, attempt to fix permissions (in case is that) before retrying and continuing.
  • Don't set file permissions too permissive, however, it's bad practice and dangerous to have folders or files writable by other processes. Set appropriate umask up front and ensure files are created with appropriate permissions.

• Some notes on memory usage:

  • Keep block items in memory until you receive a Block Proof, then persist to disk (perhaps after verification, perhaps before).
  • Holding items in memory is less reliable, so we should be careful to ensure, data is reliable, that the storage of in-memory items is not in the wrong component, and data is not duplicated unnecessarily.
  • We should be holding byte arrays mostly (not parsed items), and only parsing just enough to complete verification.

[AlfredoG87]

@ata-nas. can you consider this comment as part of this ticket?
#269 (comment)

[ata-nas]

@ata-nas. can you consider this comment as part of this ticket?
#269 (comment)

@AlfredoG87 thanks for the note. I prefer however to add it as a chore in the #309 epic, even though it is not related to that strictly, than to include the commit here. This epic is going to be quite big I presume and would not want to clutter the core logic with chores, at least not here. I will make an issue and address it however.