If moria1 fails to participate in making the consensus (e.g. it's down, or
it doesn't support the consensus method that is chosen for the consensus),
then it doesn't have a consensus for that period. It should realize it doesn't
have the newest consensus, and try to fetch one from the other authorities.

This bug is especially relevant while we have authorities that don't like
the consensus method in use -- currently dizum and dannenberg haven't upgraded,
so they never sign the consensus, so any clients (or relays!) who ask them for
a consensus have to retry elsewhere. I imagine the bug slows down bootstrapping
too.

if (authdir_mode_v3(options))
return; /* Authorities never fetch a consensus */

from update_consensus_networkstatus_downloads(). But maybe instead we should bulletproof it a little more and only fetch a consensus if either we have no consensus at all, or a certain minimum time has passed since our old one expired? Or is that unnecessary? Code investigation will be needed.

Hrm. I was thinking that we probably wanted to make authorities more reluctant to use any consensus they hadn't signed themselves, and prefer using a non-fresh consensus to a non-signed-by-us consensus, and prefer that to a non-live consensus.

But now I can't remember why. Absent a compelling reason, making this "valid_until" is probably ok.

Triage: it would be great to fix this for 0.2.2.x, but it's just as much a bug on for 0.2.1, so there's no reason to block 0.2.2. Also, it's an authority fix, so we don't need to time it to releases so much.

So if we have a consensus, we won't even think about fetching one until a random time between :02 and :32 in the next period.

That said, it looks like we try once per minute to get a new consensus, once both a) we're past that random point between :02 and :32, and b) we're past :15.

If I have my math right, for testing tor networks "b" trumps in all cases.

All of this said, what's the reasoning for the "wait at least 15 minutes" part? If it is the next voting period and we don't have a consensus, we're not going to suddenly retroactively compute one. And there's currently no other way for us to learn one besides fetching it -- that's what this bug is about. So the only merit I can see is that we spent at least 1/4 of the next period giving out our old consensus. That seems like unnecessary complexity, especially if (and we should check this) we reject the new consensus we've fetched if we don't like its signatures.

Another way to say "we spent at least 1/4 of the next period giving out our old consensus" is "we spend at least half the period where relays are asking us for an updated consensus stubbornly giving out the old one". That's no good.

If the "+ 15 minutes" thing is to handle clock skew, it's our own clock that's the only one that matters. We make the consensus, when we think we should. Nobody else is going to send us one.

Seems to me that we should put authorities in the "extra early" schedule category: