Loosen the constrains on BlockHeaders responses in ETH protocol

[rjl493456442]

In snap sync, if the response to a GetBlockHeaders request does not meet the expected requirements, the corresponding peer will be dropped.

However, due to certain limitations, such as the peer not being fully aligned with the network head and slightly lagging behind, it may be unable to serve the request with the complete set of data.

Since the request is made without knowing how many headers the peer can actually provide, the peer dropping is actually not needed.

[rjl493456442]

Example:

request is made here:

    peer.log.Trace("Fetching skeleton headers", "from", req.head, "count", requestCount)
    netreq, err := peer.peer.RequestHeadersByNumber(req.head, requestCount, 0, true, resCh)
    if err != nil {
        peer.log.Trace("Failed to request headers", "err", err)
        s.scheduleRevertRequest(req)
        return
    }
    defer netreq.Close()

remote side, which doesn't have the full set of requested data and can only provide a portion of it.

    // If the request is for future headers, we still return the portion of
    // headers that we are able to serve
    if current := hc.CurrentHeader().Number.Uint64(); current < number {
        if count > number-current {
            count -= number - current
            number = current
        } else {
            return nil
        }
    }

response is rejected

DEBUG[06-26|15:27:53.534] Joining skeleton peer                    id=810be97e6f0cf89f50587852686df1b20df1d698df31a547ff9c8e9a330ef8c2
DEBUG[06-26|15:27:53.545] Invalid header response head             peer=810be97e have=22,787,072 want=22,787,104