Sync fixes (#1716)

## Issue Addressed

chain state inconsistencies

## Proposed Changes
- a batch can be fake-failed by Range if it needs to move a peer to another chain. The peer will still send blocks/ errors / produce timeouts for those  requests, so check when we get a response from the RPC that the request id matches, instead of only the peer, since a re-request can be directed to the same peer.
- if an optimistic batch succeeds, store the attempt to avoid trying it again when quickly switching chains. Also, use it only if ahead of our current target, instead of the segment's start epoch

beacon_node/network/src/sync/network_context.rs

@@ -87,7 +87,7 @@ impl<T: EthSpec> SyncNetworkContext<T> {
         request: BlocksByRangeRequest,
         chain_id: ChainId,
         batch_id: BatchId,
-    ) -> Result<(), &'static str> {
+    ) -> Result<SyncRequestId, &'static str> {
         trace!(
             self.log,
             "Sending BlocksByRange Request";
@@ -97,7 +97,7 @@ impl<T: EthSpec> SyncNetworkContext<T> {
         );
         let req_id = self.send_rpc_request(peer_id, Request::BlocksByRange(request))?;
         self.range_requests.insert(req_id, (chain_id, batch_id));
-        Ok(())
+        Ok(req_id)
     }
 
     pub fn blocks_by_range_response(