Allow Node supermajority to SetMimir without manual Admin lock-in

For line consistency, in the below links I use v1.88.0 .

Please tell me if this should instead have been approached as an ADR.

My understanding of current Mimir behaviour:

Admin can set actual Mimir, and each Node can set its Node Mimir.

When effective Mimir is checked, if there is a current Node supermajority then this is the effective Mimir, else the actual Mimir is the effective Mimir.

Currently, it is necessary for Admin to pay attention to and lock-in a Mimir supermajority after node voting,
or else future node churn-outs could drop the vote number below a supermajority and switch effective Mimir back to Admin Mimir.

Assumptions:

Effective Mimir should only change from an active set_mimir event (and only to the value specified in that event),
not automatically during a churn while no one is paying attention.
|
(Further consideration:
If a node number decrease results in a supermajority,
then requiring an active re-vote to change effective Mimir
may be preferable to it happening without an active vote.)

At present, of Nodes and Admin, one side's passivity should not be able to prevent the other's activity.
|
As a counterexample, in future it might be that a churned-in Node automatically adopts the vote of every current supermajority,
and so supermajorities persist until there are active Node votes which change this.
However, in an emergency this would leave Admin unable to actively change effective Mimir for a supermajority which few if any of the Active nodes had deliberately voted for.

Proposal:

I propose that every attempt to set Mimir (the code in handler_mimir.go), after determining whether the attempt is from Admin or a Node (and calling SetNodeMimir if from a Node),
first check whether the previous Mimir value is different from the set_mimir value.
If not different, directly return nil.
|
Next check whether there is a supermajority for the Mimir key:
Admin only calls SetMimir (or DeleteMimir) if there is not a supermajority,
and a Node only calls SetMimir if there is a supermajority for the set_mimir value.
|
GetMimir code in keeper_mimir.go could be left as-is, with just a comment left that mentioning the handler_mimir.go handleV version
past which a later GetMimir could hypothetically only call GetKey. | However, since GetMimir calls occur more frequently than set_mimir,
I feel it is worth changing GetMimir to not call HasSuperMajority, thus improving performance.
[Edit: If GetKey needs to stay in keeper_mimir.go (handler_mimir.go using GetMimir instead), then this could also be necessary for consistency.]

Possible concerns:

By allowing Nodes' supermajority to set actual Mimir directly, a supermajority of Nodes could set the KRAKEN key if they so chose,
requiring for instance a SetMimir code change to be able to undo.
However, as by definition this represents a the will of a supermajority of (active) Nodes, this possibility appears acceptable.

If any supermajority had not already been locked-in by Admin upon implementation (initial version change),
it would be necessary to reapply it with a single vote.