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 number of
  proposers participation. Trade off made is that this may lead to the
  network getting stuck more often instead of forking.

* resend initial proposal while waiting during ESTABLISH phase

* added a dedicated state for initial proposal phase for clarity

* 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).
added new state BUILT_LEDGER to help with peers not being in sync

(see documentation updates for details)
work around for race condition

on startup there is a race condition that causes advanceLedger to be called before the peer infrastructure is fully initialized.
This works around that issue by delaying the first execution.