Fix fast sync by preventing re-downloading duplicate blocks during gap 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/9079f36b/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/9079f36b/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.