Do not reset batch ids & redownload out of range batches (#1528)

The changes are somewhat simple but should solve two issues:
- When quickly changing between chains once and a second time back again, batchIds would collide and cause havoc. 
- If we got an out of range response from a peer, sync would remain in syncing but without advancing

Changes:
- remove the batch id. Identify each batch (inside a chain) by its starting epoch. Target epochs for downloading and processing now advance by EPOCHS_PER_BATCH
- for the same reason, move the "to_be_downloaded_id" to be an epoch
- remove a sneaky line that dropped an out of range batch without downloading it
- bonus: put the chain_id in the log given to the chain. This is why explicitly logging the chain_id is removed

beacon_node/network/src/sync/mod.rs

@@ -8,7 +8,7 @@ mod range_sync;
 
 pub use manager::{BatchProcessResult, SyncMessage};
 pub use peer_sync_info::PeerSyncInfo;
-pub use range_sync::{BatchId, ChainId};
+pub use range_sync::ChainId;
 
 /// Type of id of rpc requests sent by sync
 pub type RequestId = usize;