feat: Implement a support for the new BN response BehindPublisher

[petreze]

Description:
This PR adds support for the new Block Node response BehindPublisher.

• It includes changes to the implementation in BlockNodeConnection#onNext() method to handle the new response
• Added a new metric for tracking the block number of the latest BehindPublisher received
• Adjusted the block-stream.json dashboard file accordingly
• Unit test fixes
• Additions and changes to the test-client in order to support testing the new response

Related issue(s):

Fixes #

Notes for reviewer:

! ---DO NOT MERGE BEFORE RELEASE 0.25.0 of the Block Node --- !

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[lfdt-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[timfn-hg]

BehindPublisher is not an EndStream condition and thus the connection should not be closed and started again with the new block. Additionally, there needs to be a condition to respond with an ERROR if the block requested is above the latest block produced by the CN. Basically the handling of BehindPublisher should be the exact same as handling a ResendBlock message - just logging/metrics changed.

[petreze]

The implementation is inspired from these changes in the protocol document in BN repo.
It says that the block node no longer closes the stream when behind, but
waits for the Publisher to either stream an earlier block or
send "too far behind". By sending too far behind, we are essentially closing the stream and rescheduling

[timfn-hg]

       if (blockBufferService.getBlockState(restartBlockNumber) != null) {
            logger.info("{} Block node reported it is behind. Will restart stream at block {}.", this, restartBlockNumber);

            closeAndRestart(restartBlockNumber);
        } else { ... }

The if block above calls #closeAndRestart(long). That is the part I am talking about. The document was updated to indicate this:

      BlockNode -->> Publisher: Respond with BehindPublisher and specify the latest completed block (L)
      Publisher-->>BlockNode: Send from block L+1 or send EndStream(Too Far Behind) and retry with exponential backoff

Only if the block isn't available should the connection be closed, otherwise the connection should not be closed and we should just turn around and start sending the requested block, like we do for ResendBlock