feat: Update Consumer Simulator to be more memory efficient

[mattp-swirldslabs]

As a Consumer Simulator User
I want to be able to consume the 10k TPS recording of real data with the setting blockStream.millisecondsPerBlock=500 without running out of memory in the simulator.
So that I can confirm end-to-end BN streaming.

• While testing PBJ Issue #329, I found that the Consumer Simulator would run out of memory (16GB) before consuming all 4058 blocks of the 10k TPS recording
• On a local branch, I was able to keep the Consumer Simulator at around 1 GB of memory while consuming the entire 4058 blocks of the recording to test #329. I was able to fix the memory issue by using the "Unparsed" BlockItem strategy we're using on the BN server. However, after a stand up discussion, we determined that we should NOT use the "Unparsed" strategy for the Consumer Simulator.
• Instead of "Unparsed" types, we need to find ways to conserve memory without changing the existing protoc types if possible.

Tech Notes

• Getting to the point where you can see the OutOfMemoryError on the Consumer Simulator may require the Helidon fixes coming in 4.2.0-SNAPSHOT. Here's how you can get these HTTP/2 fixes to run the 10k TPS recording successfully from the producer -> BN -> consumer:

0. Prerequisite: install Maven. I used version 3.8.7
1. On a terminal cd to a directory to clone the Helidon repo
2. git clone [email protected]:helidon-io/helidon.git && cd helidon && mvn install -DskipTests
3. In settings.gradle.kts change val helidonVersion = "4.1.1" to `val helidonVersion = "4.2.0-SNAPSHOT"
4. Build and deploy the BN container as you usually would

[jsync-swirlds]

Some brief thoughts on possible approaches:

1. Write blocks to disk in the simulator, only keep a small number (2-3) of blocks in memory at a time.
2. Drop blocks once they're read and (possibly) verified
   • This is the easiest, just don't keep things around, but we'll eventually need to be able to do more than just receive the block; we need to verify and possibly do other processing. We should be able to reuse the persistence and verification services from Block Node itself to do these things.
3. Have some sort of configurable option to not parse block items, just write them to disk, or hash them, as received (possibly not manageable with protoc generated gRPC methods).

All of these involve reducing the number of blocks in memory, which I suspect is central to making the memory impact reasonable.

[georgi-l95]

Did some testing, yes, heap grows uncontrollably.