consensus updates to limit network partitioning

* added consensus_threshold (configurable) used to enforce minimum number of peers involved during consensus. Previous implementation was using a dynamically calculated value that could get too small over time in the event of network partitioning.

* simplified logic used to determine consensus to always enforce proposers participation. Trade off made is that this may lead to the network getting stuck more often instead of forking.
  * in particular, removed special casing that was moving the node into ESTABLISH if a few nodes were already proposing (this could be wrongly triggered when transactions are still propagating in the network)

* resend initial proposal while waiting during ESTABLISH phase

* documented consensus
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).
(WIP) Exit consensus earlier when not running on the consensus ledger