…re sent

Previously, the state of `allowed_requests` will always be reset to the
default value even if there are no new block requests in the end. This
could cause an edge cause that `peer_block_request()` will early
return next time when no ongoing block requests in fact.

…p sync

When starting gap sync, the starting point is set to the last finalized block (`finalized_number`),
and `best_queued_number` is updated to this block as well, see https://github.com/paritytech/polkadot-sdk/blob/9079f36/substrate/client/network/sync/src/strategy/chain_sync.rs#L1396-L1399.
This results in a situation where the `best_queued_number` in chain sync could be
smaller than `client.info().best_number`. Consequently, when `peer_block_request()` is
invoked, blocks between `finalized_number` and `client.info().best_number` are redundantly requested.

While re-downloading a few blocks is usually not problematic, it triggers an edge case in gap sync:
when these re-downloaded blocks are imported, gap sync checks for completion by comparing `gap.end`
with the `imported_block_number`, see https://github.com/paritytech/polkadot-sdk/blob/9079f36/substrate/client/network/sync/src/strategy/chain_sync.rs#L1844-L1845
For example, if the best block is 124845 and the finalized block is 123838, gap sync starts
at 123838 with the range [1, 124845]. Blocks in the range [124839, 124845] will be re-downloaded.
Once block 124845 is imported, gap sync will incorrectly consider the sync as complete, causing
block history to fail to download.

This patch prevents re-downloading duplicate blocks, ensuring that gap sync is not stopped prematurely,
and block history is downloaded as expected.

…nto more-fast-sync-edge-case-fixes