some control protocol GETINFO downloads/networkstatus keys are lies
Some of the GETINFO downloads/networkstatus/*
keys are misleadingly named, and some can't possibly produce what they claim to do given the internal state of tor.
During bootstrap, only one flavor of consensus gets downloaded, but there are separate download schedules for mirror vs authority. After bootstrap, there are separate download schedules for each flavor of consensus. Currently, the control protocol returns authority and mirror bootstrap schedules when asked for ns and microdesc bootstrap schedules, respectively.
We should accept downloads/networkstatus/mirror/bootstrap
and downloads/networkstatus/authority/bootstrap
keywords and return the appropriate schedules.
downloads/networkstatus/ns/bootstrap
and downloads/networkstatus/microdesc/bootstrap
should only return valid results for the flavor we're using to bootstrap. There is the question of whether to return the mirror or authority schedule.
If the controller doesn't specify bootstrap vs running, should we use the "running" schedule during bootstrap if we're asked for a flavor that we're not using to bootstrap?
We should return an error code like 552
(unrecognized entity -- or is a different code better here?) if the requested information isn't available.
Thanks to teor for feedback.