refactor: BlockAsDirReader and BlockAsDirWriter review and overhaul

[ata-nas]

Story

AS A BN Developer
I WANT a review and overhaul if needed of the BlockAsDirReader and BlockAsDirWriter
SO THAT concerns about current implementation are addressed and we are assured of their proper functioning.

Tech Notes

Based on this comment and the thread that proceeds it, there are a few concerns with the current implementation of the BlockAsDirReader and BlockAsDirWriter, mainly:

• currently both classes have a filed member filePerms which make no distinction between file and folder permissions
• it is important that files and folders have a different set of permissions, so such distinction should be made if necessarry
• it must be discussed if we should continue to use permissions like we do currently or another approach must be used, see comment

UPDATE:

• these must now be integrated based on the changes in EPIC: Essential Block Storage and Retrieval Support #309 and need to be matched under the abstractions that will now be adapted

[AlfredoG87]

I don't think is worth it to continue to work on these implementations since we should remove them once the BlockAsFile Writer and Reader are completed.

[ata-nas]

I don't think is worth it to continue to work on these implementations since we should remove them once the BlockAsFile Writer and Reader are completed.

@AlfredoG87 during the implementation of #272 we reached the conclusion that we should revise these implementations here. It is true that if we shall delete them we should not work any longer over them, but my understanding is that the BlockAsDirReader and BlockAsDirWriter should NOT be deleted, @jsync-swirlds am I right about that?

[jsync-swirlds]

I don't think is worth it to continue to work on these implementations since we should remove them once the BlockAsFile Writer and Reader are completed.

There is no good reason to remove these implementations, as they're still useful for testing, debugging, and development. Certainly they are not production implementations, but at most I could see moving them to a testFixtures module (and I'm not certain we need to do that).

The persistence service should have multiple reader and writer implementations both to allow for flexibility in deployment and to ensure we continue to write the system with that required flexibility in mind.
Example scenarios
What if I want to deploy a block node that only stores the last few hours of blocks, without compression?
What if I want a block node that stores the individual items on disk for another process to pick up?