feat: Add messages for skip and resend block to block service

* Added skip block message to block service `PublishStreamResponse`
* Added resend block message to block service `PublishStreamResponse`
* Renamed end of stream response to `end_of_stream` for clarity.
* Added persitence failed response
* Removed (unnecessary) item acknowledgement

Signed-off-by: Joseph Sinclair <121976561+jsync-swirlds@users.noreply.github.com>

Author: jsync-swirlds

HIP/hip-1081.md

@@ -13,7 +13,7 @@ needs-council-approval: Yes
 status: Draft
 created: 2024-05-15
 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/1055
-updated: 2024-12-10
+updated: 2025-02-28
 requires: 1056
 ---
 
@@ -109,6 +109,9 @@ The block node will support semantic version values and will make it's current v
 
 1. As a block node operator I want to collect all of the information, in the form of block streams, produced by
 consensus nodes.
+1. As a block node operator I want to accept blocks from multiple consensus nodes.
+1. As a block node operator I want to tell all but one consensus node to skip the current block and resume sending data
+with the next block.
 2. As a block node operator I want to verify the network signature in a block proof and assert block integrity.
 3. As a block node operator I want to persist and maintain a complete and correct copy of the latest state.
 4. As a block node operator I want to offer a streaming API that provides access to a real time unverified block stream
@@ -160,22 +163,25 @@ The Block node will support the streaming and parsing of Block Stream messages i
 in the [hedera-protobuf repository](https://github.com/hashgraph/hedera-protobufs/tree/main/block/stream).
 
 There are a few cases where a stream requires consideration from the Block Node
-1. Protobuf version upgrades: ...details to be added.
+1. Protobuf version upgrades: The backward and forward compatibility built into protocol buffers makes versioning the
+protocol buffer specification largely unnecessary, and also ensures that future software versions will always be able
+to read, verify, and process older block stream data.
 2. Pause in stream due to CN upgrades: The CN has historically carried out monthly coordinated upgrades of its software.
     This will remain an normal disruption in the data stream that a block node must support. In this case a block node
     will expect an end-of-stream response from a CN which it will gracefully manage.
 3. No Block Proof: Each block stream in the block stream (with the exception of record file
     block items) is terminated with a block proof that provides the confidence of network verification of the block at
     hand. The lack of a block proof over a prolonged time is a signal to the block node that the CN has encountered an
-    issue calculating the proof - either due to falling behind consensus or due to a potential ISS. A block node will maintain its connection and will manage an
-    end-of-stream in the case the CN falls behind. Here, open subscriber connections that are streaming live block items out will likely be terminated after an
+    issue calculating the proof - either due to falling behind consensus or due to a potential ISS. A block node will 
+    maintain its connection and will manage an
+    end-of-stream in the case the CN falls behind. Here, open subscriber connections that are streaming live block
+   items out will likely be terminated after an
     established period of time. In such a case the block node may potentially observe the connection
     and persist the given current and previous block contents to aid in troubleshooting of the stream.
 4. Delayed Block Proof: A delayed block proof may be followed by the receipt of a cascade proof. This is a where an earlier
-    block is proved using a later blocks signature with a chain of previous block hashes. In this case the block node
+    block is proved using a later block signature with a chain of previous block hashes. In this case the block node
     will still eventually receive a block proof for every block. 
 
-
 ### Services
 To achieve the above the block node will offer multiple pluggable modular services which can be enabled by node
 operators.