Don't Panic if 0 Peers are Left

[nisdas]

• Instead of returning an error and halting the node, we simply the log the error and re-send the request.
• Use a more static finalized epoch, so it isnt badly affected by a large drop in peers.

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (master@20fef0b). Click here to learn what that means.
The diff coverage is 0%.

@@           Coverage Diff            @@
##             master   #4594   +/-   ##
========================================
  Coverage          ?   6.82%           
========================================
  Files             ?     192           
  Lines             ?   13236           
  Branches          ?       0           
========================================
  Hits              ?     904           
  Misses            ?   12198           
  Partials          ?     134

[shayzluf]

the result of this change can be great . as it stays the same epoch throughout initial sync.
the result as i see it will be that the best peer will be requested for all epochs from this initial value that was set at the beginning of sync to the new finalised epoch that is the current one (maybe a day later). this can put a lot of stress on one peer.
maybe something like this can be done to resolve this issue?

Suggested change

	for s.chain.HeadSlot() < highestFinalizedSlot {
	for s.chain.HeadSlot() < max(highestFinalizedSlot,helpers.StartSlot(s.highestFinalizedEpoch() + 1)) {

[nisdas]

it doesn't stay the same, we just ensure there are a safe amount of peers before updating it . Below there is this piece of code:

	if len(peers) >= flags.Get().MinimumSyncPeers {
			highestFinalizedSlot = helpers.StartSlot(finalizedEpoch + 1)
		}

[shayzluf]

missed it. thanks