Validators should not serve BlockRequests

[DrZoltanFazekas]

Syncing nodes can't distinguish the current validators from other nodes since their latest block contains an outdated validator set. But they validators can advertise that they don't have any blocks so that nodes don't send them request for blocks that they want to download.

[shawn-zil]

When we alter the Validators so that they will always respond with a 'null' response (to indicate that they don't have any blocks) the requesting node retries the range with a different peer. This is desired behaviour.

However, it creates a potential dead-lock. By definition, the non-Validators are generally 'behind' the Validators. In the rare case where restarted Validators are trying to sync, they may not be able to if the only nodes that have the latest blocks are other Validators as the latest blocks have not propagated to non-Validators. This can happen e.g. when the network is restarted before the latest blocks get propagated to the non-Validators.

As seen in this example where the Validator is requesting for blocks [770..772] but the non-Validators only have < 771.

zilliqanode2  | 2024-12-19T03:08:42.714937Z  WARN zilliqa::node: 292: block_store::BlockRequest : sending empty block response.
zilliqanode2  | 2024-12-19T03:08:42.716387Z  WARN zilliqa::block_store: 1014: block_store::request_blocks() : Could not find peers for views RangeMap { ranges: [770..772] }
zilliqanode2  | 2024-12-19T03:08:43.067254Z  INFO zilliqa::node: 967: block response from: 12D3KooWPXw2dXBRH1bT4vcNos9f6W2KoFTiarqptBuTzxaXg7zu len: 0 availability: None
zilliqanode3  | 2024-12-19T03:08:43.069067Z  INFO zilliqa::node: 967: block response from: 12D3KooWNtUCTB4J5MzXc3wawYic4m4pRwTLSL4BzTQc2Csk3VfL len: 1 availability: Some([Latest(10), CachedViewRange(0..771, None)])

Possible solutions:

1. We will allow Validators to serve BlockRequests from other Validators only; and deny servicing BlockRequests from non-Validators; or
2. We ignore this edge-case and assume that we will always have some sub-set of nodes running and propagating the latest blocks.
3. We work out some other mechanism to do this.

I've implement the first solution for now, unless we think that a different solution makes more sense.