Reduce occurrences of firststep_verifyCandidateBlock warnings

[goshawk-3]

Describe the bug
Too many firststep_verifyCandidateBlock failed errors/warnings are being reported in a live network. This is most probably due to a race between Chain component accepting next valid block and Consensus loop goroutine still running next iteration 1st Reduction of the same round.

Collected from testnet-daybreak node-0. Similar errors counts are found on all nodes.

node-0:~# zgrep -c "firststep_verifyCandidateBlock failed"  /var/log/dusk.log-*.gz 
/var/log/dusk.log-20220412.gz:963
/var/log/dusk.log-20220417.gz:311
/var/log/dusk.log-20220424.gz:342
/var/log/dusk.log-20220501.gz:138
/var/log/dusk.log-20220508.gz:135
/var/log/dusk.log-20220515.gz:138
/var/log/dusk.log-20220522.gz:129
/var/log/dusk.log-20220529.gz:165


{"error":"block already exists","level":"error","msg":"firststep_verifyCandidateBlock failed","round":636087,"step":2,"time":"2022-05-20T09:24:04Z"}
{"error":"previous block hash does not equal the previous hash in the current block","level":"error","msg":"firststep_verifyCandidateBlock failed","round":636190,"step":5,"time":"2022-05-20T09:37:16Z"}

To Reproduce
The race is mostly reproducible on testnet.

Expected behaviour

These warnings pollute log files. We should expect to see firststep_verifyCandidateBlock failed on any misuse or edge case occurrences, alarming for something that needs to be investigated.

Platform
Testnet-daybreak

Additional context
NB that firststep_verifyCandidateBlock failed has been renamed to verifyfn failed. Once dusk service is updated on testnet, we should re-grep for verifyfn failed and if it's still reported too often, we should investigate/address it further.