Properly handle `ValidBlockStart` for dBFT extensibles

[AnnaShaleva]

Rationale

Ref. discussion under the #298 (comment). Currently dBFT protocol messages always have ValidBlockStart set to 0. It makes the stale nodes to receive and try to verify messages from future heights:

go-ethereum/eth/protocols/dbft/pool.go

Lines 84 to 92 in 7717358

	h := p.chain.BlockHeight()
	if h < m.ValidBlockStart || m.ValidBlockEnd <= h {
	// We can receive a consensus payload for the last or next block
	// which leads to an unwanted node disconnect.
	if m.ValidBlockEnd == h {
	return false, nil
	}
	return false, errInvalidHeight
	}

#298 makes the node to skip the payload verification if the node is in the process of the initial sync. However, Downloader does not activate immediately after the node start, it takes some time for it to start chain sync. Thus some "Can't validate payload" messages still may appear in the start of the out-of-date node.

Implementation

We need to properly set dBFT's payloads ValidBlockStart to some CurrentHeight - 5 height. We should also adjust dBFT's payloads verification rule in order to skip "future" payloads handling based on ValidBlockStart without peer disconnection.