Threshold check in PBFT

[edsko]

After #2169 , nodes can now indicate that they are a leader for a slot, but cannot lead due to some problem. For PBFT, this problem could be that the key does not match the delegation state (#2172), but it could also mean that the block would exceed the PBFT window threshold.

Right now we don't check for this in PBFT. Initially I thought that doing so would be wrong, because it means that I could force you to give up your slot simply by producing few blocks myself. However, if a node produces a block ignoring this, that block would anyway promptly be discarded (by its own node!) as invalid, so there is no reason not to do the check.

The absence of the check means that the consensus tests need to make sure that the threshold does not get exceeded, or else they end up with invalid blocks. Introducing this check would allow us to lift that restriction. It would also give a better log message should this ever happen in real life, although in reality we don't expect this to ever happen, which is why I've marked this purely as a testing ticket.

[nfrisby]

To clarify: this ticket is a follow-on to Issue 2172 that expands the task therein from just checking the key is OK (up-to-date delegation map, etc) to also checking that the PBFT window threshold is satisfied, right?

[edsko]

Correct.

[edsko]

because it means that I could force you to give up your slot simply by producing few blocks myself.

actually, this is doubly incorrect. Not only would producing a block be pointless in this case anyway (as I mention in the last paragraph in the ticket description), but also, the threshold is computed over the window size, independent from the slots filled by other nodes.

[edsko]

Closed in #2176 .