tune down thresholds for close time consensus

With the consensus changes, the chance of some nodes considered stuck in the "ESTABLISH" phase is higher, which would cause such nodes to be very unlikely to change their position wrt close time.
This change leaves room for nodes to converge towards close time.

Trade off being made is that close time is easier to game: in the early stage of consensus in the event that the network is heavily partitioned (in the form of most nodes come up with their own close time) a group representing 30% of the nodes will influence the others. This influence would be temporary and does not impact other parts of the network that are critical (transaction set, ledger sequence number).

src/ripple_app/consensus/LedgerConsensus.cpp

@@ -1558,13 +1558,13 @@ class LedgerConsensusImp
         int neededWeight;
 
         if (mClosePercent < AV_MID_CONSENSUS_TIME)
-            neededWeight = AV_INIT_CONSENSUS_PCT;
+            neededWeight = AV_INIT_CT_CONSENSUS_PCT;
         else if (mClosePercent < AV_LATE_CONSENSUS_TIME)
-            neededWeight = AV_MID_CONSENSUS_PCT;
+            neededWeight = AV_MID_CT_CONSENSUS_PCT;
         else if (mClosePercent < AV_STUCK_CONSENSUS_TIME)
-            neededWeight = AV_LATE_CONSENSUS_PCT;
+            neededWeight = AV_LATE_CT_CONSENSUS_PCT;
         else
-            neededWeight = AV_STUCK_CONSENSUS_PCT;
+            neededWeight = AV_STUCK_CT_CONSENSUS_PCT;
 
         std::uint32_t closeTime = 0;
         mHaveCloseTimeConsensus = false;

src/ripple_app/consensus/Legacy_consensus.txt

@@ -146,14 +146,10 @@ on messages it gets from the network.
 
 The local instance will change its close time towards a larger majority
 subset: it will snap to the largest group if possible. A group is
-considered "valid" if it represents more than 50% of the peers, then
-evolves to up to 95% if consensus is stuck (see AV_INIT_CONSENSUS_PCT).
+considered "valid" if it represents more than 30% of the peers, then
+evolves to up to 51% if consensus is stuck (see AV_INIT_CONSENSUS_PCT).
 To consider that consensus is met on the close time the percentage has to
-be higher than AV_CT_CONSENSUS_PCT and the group has to be valid.
-
-!!!!!!!! Open: it seems that we can be in situations where 80% of the peers
-         agree yet we don't consider this consensus because of this notion
-         of validity.
+be higher than AV_CT_CONSENSUS_PCT (75%) and the group has to be valid.
 
 3.3.2 Declaring consensus
 

src/ripple_app/ledger/LedgerTiming.h

@@ -64,17 +64,21 @@ namespace ripple {
 
 // Avalanche tuning
 #   define AV_INIT_CONSENSUS_PCT    50  // percentage of nodes on our UNL that must vote yes
+#   define AV_INIT_CT_CONSENSUS_PCT 30  // smallest group (in % of UNL) used for consensus time consensus
 
 #   define AV_MID_CONSENSUS_TIME    50  // percentage of previous close time before we advance
 #   define AV_MID_CONSENSUS_PCT     65  // percentage of nodes that most vote yes after advancing
+#   define AV_MID_CT_CONSENSUS_PCT  30  // smallest group (in % of UNL) used for consensus time consensus
 
 #   define AV_LATE_CONSENSUS_TIME   85  // percentage of previous close time before we advance
 #   define AV_LATE_CONSENSUS_PCT    70  // percentage of nodes that most vote yes after advancing
+#   define AV_LATE_CT_CONSENSUS_PCT 40  // smallest group (in % of UNL) used for consensus time consensus
 
 #   define AV_STUCK_CONSENSUS_TIME  200
 #   define AV_STUCK_CONSENSUS_PCT   95
+#   define AV_STUCK_CT_CONSENSUS_PCT 51  // smallest group (in % of UNL) used for consensus time consensus
 
-#   define AV_CT_CONSENSUS_PCT      75
+#   define AV_CT_CONSENSUS_PCT      75   // % of UNL needed to agree on a close time to call consensus
 
 class ContinuousLedgerTiming
 {