Reconsider block production when system under heavy load

[edsko]

The first thing that happens in block production is a check to see if perhaps we already received a block for the very same slot from another node; this can happen (theoretically speaking) if there are multiple slot leaders and the other node manages to produce their block and have it sent to and adopted by us before we manage to produce our own block.

So we check the current chain, and look at the block at the tip of the chain. If that block has the same slot number as the slot we're trying to produce a block for, we go back one block, basically rolling back one.

If however the block at the tip of the chain has a slot number larger than the current slot number, it means the system must have been under such heavy load that one or more slots passed in between the start of the leadership check and the call to the chain DB. When this happens, we currently just give up and don't produce a block.

We may wish to reconsider this, though we should be a bit careful. See detailed comments in prevPointAndBlockNo in forkBlockProduction.

[deepfire]

Could this be potentially causing the reduced leadership check frequency observed in https://input-output.atlassian.net/wiki/spaces/BM/pages/1663827969/GH-1769+BUG+-+chain+stopped+for+more+than+4+minutes+on+producer+relays ? We have 100% CPU utilisation there.