Fix proposal policy transition rules

[linh2931]

Consider the following case:

1. In round 1, a block proposes a proposer policy.
2. In round 2, the block in the 12th time slot of the round is not present.
3. In round 3, there exists at least one block.

In the current implementation, the first block in round 3 will not use the proposer policy that was proposed in round 1 despite that being our intention. That would however be the case if there was a block present in the 12th time slot of round 2.

Fixing the bug means that at the time of building a new block that is the first block of a round, it will always choose as the active proposal policy the last proposed proposer policy in the blockchain that was not proposed from a block in the current round or the one prior.

Instead of a map to track all the proposed proposal policies in the block_header_state, only two optional fields: latest_pending_proposer_policy and latest_proposed_proposer_policy are needed. Additionally, instead of tracking an active_time with each proposed policy, we just track the timestamp in which it was proposed: proposal_time.

When creating a block_header_state for the first block of a round, those fields are computed by:

1. If latest_proposed_proposer_policy is not nullopt and its proposal_time indicates that it was proposed in a round before the prior round, then promote latest_proposed_proposer_policy to active_proposer_policy. latest_pending_proposer_policy and latest_proposed_proposer_policy should be set to nullopt at this point in time (latest_proposed_proposer_policy may still be changed in later steps).
2. Otherwise, if latest_pending_proposer_policy is not nullopt, promote latest_pending_proposer_policy to active_proposer_policy. latest_pending_proposer_policy should be set to nullopt at this point in time (may still be changed in later steps).
3. If latest_proposed_proposer_policy is not nullopt and latest_pending_proposer_policy is now nullopt, latest_proposed_proposer_policy is moved into latest_pending_proposer_policy. If it is moved, then latest_proposed_proposer_policy is set to nullopt at this point in time (may still be changed in later steps).

The final related step should occur for any block (whether it is the first block of the round or not) and can only be computed after the block has been assembled:

4. If this block proposes a new proposer policy, that policy should be set in latest_proposed_proposer_policy (replacing whatever happened to be there).

Resolves #454

[linh2931]

@heifner The commit 59e716e passed most tests, but failed a few. Can you see anything obviously wrong? Thanks.

unittests/unit_test -t producer_schedule_savanna_tests
Random number generator seeded to 1723148650
Running 5 test cases...
unittests/producer_schedule_savanna_tests.cpp(35): error: in "producer_schedule_savanna_tests/verify_producer_schedule_after_savanna_activation": check head().block_num() == expected_block_num has failed [25 != 24]
unittests/producer_schedule_savanna_tests.cpp(35): error: in "producer_schedule_savanna_tests/verify_producer_schedule_after_savanna_activation": check head().block_num() == expected_block_num has failed [49 != 48]
unittests/producer_schedule_savanna_tests.cpp(364): error: in "producer_schedule_savanna_tests/proposer_policy_progression_test": check 17u == control->active_producers().version has failed [17 != 12]
unittests/producer_schedule_savanna_tests.cpp(367): error: in "producer_schedule_savanna_tests/proposer_policy_progression_test": check 22u == control->active_producers().version has failed [22 != 17]
nittests/producer_schedule_savanna_tests.cpp(468): error: in "producer_schedule_savanna_tests/policy_switching_corner_case_test": check b->producer == "alice"_n has failed [eosio != alice]

[linh2931]

@arhag The current PR has not implemented the enhancement described by #454:

not promote the policy if the proposal_time of the policy is greater than the last_final_block_timestamp (computed after considering the claim of the current block).

This is due to the fact the producer_plugin needs to know the producer for the next block

spring/plugins/producer_plugin/producer_plugin.cpp

Line 1795 in ea5c025

const producer_authority scheduled_producer = chain.active_producers().get_scheduled_producer(block_time);

But at that time we don't know the QC claim of the next block and cannot calculate the last_final_block_timestamp.

But we know the last_final_block_timestamp of the head block. We could check against it. This will miss one corner case that if the next block advances the LIB.

[ericpassmore]

Note:start
group: STABILITY
category: INTERNALS
summary: Improve finalizer policy transition by always promoting a proposer policy to active on the first block of a round. That proposer policy should never be the one that was proposed in the prior round. It should have been proposed at least two rounds back.
Note:end

[greg7mdp]

Is this correct? We need a timestamp to know if these will be active.

[linh2931]

This is changed to pending_producers.

[greg7mdp]

This still seems like an odd API to me. What do we need it for?

[linh2931]

By net_plugin and chain_plugin. Please see the discussion in telegram channel.