[consensus::simplex] Stable-Leader: Allow for leaders to serve for a "term" of consecutive views.

[BrendanChou]

In order to get stable leaders in simplex, we introduce the concept of a “term.” A term is a number of contiguous views in which the leader is stable. If there is ever a nullification formed in a term, participants can skip the rest of the term. That is, a nullification serves as a nullification for the view that it is formed in, as well as all nullifications until the end of the term inclusive.

For safety, this means that nodes must not vote to finalize any block in a term if they have voted to nullify a previous block in that term and have seen no finalization certificate greater than the greatest view that they have voted to nullify.

Implementation Details

• term_length should be defined as a non-zero configuration option in Simplex.
• Validators may find messages “interesting” not only if they are in near-future views, but also in views at-or-near the start of the next term.
• If using a VRF for leader election, then the VRF signatures on nullifications should sign for the final view in the term. Note that this can lead to an easier attack on the VRF over the course of a term, allowing people to piece together the VRF signature before the end of a term. Another alternative is to establish the next leader from the VRF signature of the first slot in the preceding term.
• While voting nullify is typically due to timeout, for longer terms, we could also consider allowing the application to issue nullify votes for any other behavior. For example, if the leader is censoring transactions, a validator could issue a nullify vote (either instead-of or in-addition-to a notarize vote). In this way, nullification also serves as a request to rotate the leader since a stable leader has much more power within a term, especially when the term is long.