Fix: Don't flag consensus as stalled prematurely (#5627)

Fix stalled consensus detection to prevent false positives in situations where there are no disputed transactions.

Stalled consensus detection was added to 2.5.0 in response to a network consensus halt that caused a round to run for over an hour. However, it has a flaw that makes it very easy to have false positives. Those false positives are usually mitigated by other checks that prevent them from having an effect, but there have been several instances of validators "running ahead" because there are circumstances where the other checks are "successful", allowing the stall state to be checked.

src/xrpld/consensus/Consensus.cpp

@@ -139,11 +139,11 @@ checkConsensusReached(
         return false;
     }
 
-    // We only get stalled when every disputed transaction unequivocally has 80%
-    // (minConsensusPct) agreement, either for or against. That is: either under
-    // 20% or over 80% consensus (repectively "nay" or "yay"). This prevents
-    // manipulation by a minority of byzantine peers of which transactions make
-    // the cut to get into the ledger.
+    // We only get stalled when there are disputed transactions and all of them
+    // unequivocally have 80% (minConsensusPct) agreement, either for or
+    // against. That is: either under 20% or over 80% consensus (repectively
+    // "nay" or "yay"). This prevents manipulation by a minority of byzantine
+    // peers of which transactions make the cut to get into the ledger.
     if (stalled)
     {
         CLOG(clog) << "consensus stalled. ";