fix: height restart during app-decision failures

[insumity]

Problem

The notion of restarting exists in Malachite. Specifically, it stems from here and is intended to "solve" this problem:

In our specific case, we're unable to commit a Decided value because the node just started up and is missing the proposal (stored only in memory). We can handle this specific case, but if there are other unforeseen errors, it would be helpful to have a way to let malachite know to restart from the previous height as a way for the application to "retry" the height.

So, in case, they try to store the decided value but fail to do so, they restart the height. See an example here.

However, it does not seem reasonable to restart a height in case you fail to store the decided value, etc. In my view, the value should be retrieved only through value sync.

Additionally see this:

/// # Warning
/// This operation should be used with extreme caution as it can lead to safety violations:
/// 1. The application must clean all state associated with the height for which commit has failed
/// 2. Since consensus resets its write-ahead log, the node may equivocate on proposals and votes
///    for the restarted height, potentially violating protocol safety

because restarts are automatically performed by Malachite I do not understand how a case of equivocation can be prevented. Yes, applications should be careful when using RestartHeight but maybe it would be better if they could not use RestartHeight altogether.
In case of an app-decision failure, it would seem more natural to me to halt the chain or only try to commit a value if you've already received the value from value sync.

[insumity]

Additionally, restarts cause problem(s) in relation to sync:

• In case of a Restart, the consensus engine still sends a Decided message to the sync actor. This Decided message might erroneously update the tip_heigtht of the sync actor although we have not really reached tip_height.

• It also complicates the pruning of older heights in on_started_height because it's not clear whether we should prune height or not. For instance, if height stems from a Restart that was triggered due to a received sync-value response that an application failed to commit, then height should be pruned, but if height stems from a non-sync-related Restart, then it's not clear that we should prune (e.g., maybe we're still waiting for a sync-value response for this height).