expired consensus causes guard selection to stall at BOOTSTRAP PROGRESS=80
Tor can report BOOTSTRAP_STATUS_CONN_OR (PROGRESS=80, "Connecting to the Tor network") when it actually can do no such thing. In some situations (e.g., clock skew) this causes progress to get stuck at 80% indefinitely, resulting in very poor user experience.
Right now update_router_have_minimum_dir_info() reports the BOOTSTRAP_STATUS_CONN_OR event if there's a "reasonably live" consensus and enough descriptors downloaded. A client with a clock skewed several hours into the future can get stalled here indefinitely due to inability to select a guard: if the client's clock is skewed, it will never have a live consensus. (Guard selection seems to require a non-expired consensus, rather than a reasonably live consensus at least during bootstrap.)
We should either relax the guard selection consensus liveness requirement, or avoid reporting BOOTSTRAP_STATUS_CONN_OR when we have no reasonable chance of actually connecting to a guard for building application circuits.
Arguably we shouldn't start downloading descriptors until we have a non-expired consensus either, because that gets represented as a considerable chunk of the progress bar (40%->80%) in a way that could be misleading to a user. Making that change without additional work would cause bootstrap to get stuck at 40% instead of 80%, which might be an improvement. This can already happen if the client's clock is skewed several hours in the past.