This reverts commit a63b4148.

The "typo" wasn't actually a typo.  The "r" in the suffixes for the
release branches is meant to make them distinct from the maint
branches.

Now, _right now_, nothing uses release branch suffixes, but it's
important to keep them distinct if we decide to use them in the
future.

Also, fix a typo.

Signed-off-by: David Goulet <dgoulet@torproject.org>

Nick Mathewson authored 5 years ago and David Goulet committed 5 years ago

This will be used for 32121

Fixes bug 33531; bugfix on 0.3.3.1-alpha.

In this case, when we're looking for the voting interval, we should
try looking at the _latest_ consensus if we have one.  When we're
looking for the start of the current voting period, we can use our
existing fallback logic without complaint, since the voting interval
code will already have given us a reasonable voting interval, and we
want to have a round starting time based on the current time.

This is not as clean a patch as I would like: see the comment on
ASSUME_AUTHORITY_SCHEDULING. This issue here is that the unit tests
sometimes assume that we are going to be looking at the dirauth
options and behaving like a dirauth, but without setting the options
to turn is into one.

This isn't an issue for actually running Tor, as far as I can tell
with chutney.

This should improve the usability of our configuration error messages.

Part of 33460.

Part of 33460.

Most of this function was about recreating a voting schedule on
demand if it didn't exist yet or was not up-to-date.  I've made that
into its own function.

This is an automated commit, generated by this command:

./scripts/maint/rename_c_identifier.py \
        voting_schedule_recalculate_timing dirauth_sched_recalculate_timing \
        voting_schedule_get_start_of_next_interval voting_sched_get_start_of_interval_after \
        voting_schedule_get_next_valid_after_time dirauth_sched_get_next_valid_after_time

The 'voting_schdule_get_start_of_next_interval' function isn't
actually dirauth-specific.

Process uses evloop, and so should be initialized after it.

Pubsub events are not supposed to have their own subsystems; they're
supposed to be part of a parent subsystem.

Previously we had initialized only the library subsystems.  This
made it hard to write some tests, and encouraged people to put their
subsystems at a level lower than they really belonged at.  Instead,
it probably just makes sense to initialize everything before we
start the tests.

Without this fix, 33316 breaks our tests because of raising the
level of the ocirc/orconn events.

This code was in our process module, but it doesn't belong there:
process is for launching and monitoring subprocesses, not for
hardening the current process.

This change lets us have our subsystem init order more closely match
our dependency order.