Only log a block voting error if top version is higher and isn't ideal fork version

[thaerkh]

This is less likely to occur in Monero since it has a much larger hash rate, but it's possible that there are nodes mining a higher version but is forked from somewhere it's known to be otherwise (i.e. at a checkpoint that's known to be v6).
The behaviour this avoids is logging a false positive indicating a potential protocol upgrade.
I speculate that without this PR, the error may trigger if a chain fork like MoneroV doesn't properly configure their network and are broadcasting to Monero daemons.

[moneromooo-monero]

It also filters outs true positives though.

[thaerkh]

When ideal version at a given height is equal to the ideal version overall, being less than hshd.top_version implies that it's unknown and bigger than fork versions known (i.e. if I was running v6, and are getting v7 top versions from broadcasting nodes).
The intended behaviour for ensuring the log occurs has been confirmed on a testnet, and omission on a mainnet that has somebody broadcasting v7 blocks in v2 checkpointed heights (ideal fork version there is 4).
I might be missing an edge case though, can you elaborate on what you mean?

[moneromooo-monero]

In the past, we've brought a fork forward slightly when we had a planned fork, then needed to make an additional change to consensus rules. I think this would silence that one. It's a rare case I guess since it'd apply to someone who's running a master build, so these people should know what they're doing.

[moneromooo-monero]

Could you please also PR this to the release-0.12 branch ? It'd be nice to get it active for the september fork.

[thaerkh]

You'll find a copy of the PR referenced above, as requested

[fluffypony]

Reviewed