Finalizer doesn't create the vote after the checkpoint is processed

[kostyantyn]

Describe the bug As tests from the following PR https://github.com/dtr-org/unit-e/pull/617 show, the finalizer creates the vote once it sees the first block of the new epoch. It means that the first block will never have votes for the previous epoch, only the 2nd one.

To Reproduce To reproduce the issue, it's enough to run rpc_finalization.py test and observe the behavior.

Expected behavior I'd expect that finalizer creates the vote and puts it in the mempool once the checkpoint is processed. In this case, the first block of a new epoch can already contain votes which finalize the previous epoch.

[kostyantyn]

When we start working on this issue, we should check that finalizer can vote at any point, right after the checkpoint, after first block and so on until the next checkpoint. But it shouldn't create the vote when the checkpoint is processed as it's time to switch the epoch.

[thothd]

When you say you expect the finalizer to vote in a certain way (after the checkpoint) is it from security perspective or because that's how you assume the client should behave? I'm not sure it's a bug but maybe a potential improvement to the way finalizers are voting? since it shouldn't affect the overall behaviour of the system that much

[kostyantyn]

This is how I assume the finalizer should behave. I think it should try to vote after each processed block. And after processing the checkpoint, only the target/source should be updated. Currently, finalizer will try to vote after each block except the block which represents the checkpoint. Because of that finalizer will have 49 * 16 seconds (instead of 50 * 16) seconds to vote and make sure the vote was propagated through the network.

[kostyantyn]

Open a bit related issue https://github.com/dtr-org/unit-e/issues/652 that we don't accept the votes from the future. To ensure that the node can accept votes right after the checkpoint, it will require to modify how we validate them.