* ADDS new section, "§5.1. Guard selection algorithm", to path-spec.txt.
 * FIXES #17261: https://bugs.torproject.org/17261

Signed-off-by: David Goulet <dgoulet@ev0ke.net>

Clarify the format of the HS_DESC Replica field and indicate that it is
is defined in rend-spec.txt. Resolves #17226.

Also improve implementation notes.

And various other fixups

Make one authority connection early so the client can check its clock.
Redo the analysis for the new timing schedule.

Add IPv4 and IPv6 alternation scheme for clients that have both an
IPv4 and IPv6 address.

Add retry timer maximum and retry timer reset events.

Include min and max fallback directory weights.

Just fixing some line wrap and case (keywords like 'SHOULD' are uppercase by
convention).

To implement #4483 we need to contact multiple directory mirrors
to increase bootstrap reliability. This patch implements the
exponential backoff suggested in
https://trac.torproject.org/projects/tor/ticket/4483#comment:22

The patch also analyses the reliability of the new scheme, and
compares it to the current Tor implementation.

Also fix a typo pointed out by Marc Juarez, and perform some other misc
cleanups.

Changes:

* A zero machines.transition_burst_events means an immediate
  transition to the burst state.
* Added RELAY_PADDING_TRANSITION_EVENT_BINS_EMPTY to allow a state
  transition when the bins become empty.
* Change remove_tokens to allow client to specify removal direction
  for non-padding packets.
* Make RELAY_COMMAND_PADDING_SCHEDULE take a variable number of scheduled
  times.
* Increase and clarify rate limits.

Forgetting to specify the infinity transitions causes the state machine to
just shut down.

Also clarify terminology and address some formatting issues.

Also allow the histograms to be variable in size.

This is the version initially posted to tor-dev@lists.

Now I've updated the status of everything in my proposal-status
list.

Also let's get our pronouns correct

To be conservative, I'm saying that the proposal editors are everybody
with commit rights, except for Roger, who is way too busy :)

 * ADD a new section detailing loose-source routed circuits, including:
     - How the circuit should appear to the OP, the bridge, and the
       bridge guard,
     - How the hop(s) in the path is/are chosen,
     - How the first hop is handled and how circuit extension is
       handled, in a generalised sense (i.e. not specific to a bridge
       using bridge guards),
     - Which cell types are used and how they are chosen,
     - When the original create cell is answered (in relation to when
       cells are sent to the other additional hops),
     - What should be done when relay cells are received when the
       additional hops in the loose-source routed circuit are not
       fully constructed,
     - How the circuit crypto and cell digests for incoming/outgoing
       relay cells works (again, in a generalised sense, i.e. not
       specific to bridges using bridge guards),
     - How and whether a given relay cell is treated as "recognized",
     - Under what circumstances (based on whether a stream is attached
       and which relay command was sent) should cause a node which
       uses loose-source routed circuits to drop a relay cell or mark
       a circuit for close, and,
     - When and what statistics should be gathered for loose-source
       routed circuits.

 * UPDATE and clarify the example loose-source routed circuit
   construction (the original one from the proposal which was specific
   to a client using a bridge that uses bridge guards).

 * CHANGE the "Make it harder to tell clients from bridges" section
   which described the tradeoffs between using CREATE versus
   CREATE_FAST cells for the first additional hop (i.e. the bridge
   guard).  Those concerns is no longer entirely relevant, since, in
   the meantime, we've introduced the NTor handshake and it's
   extremely likely that both the client and the bridge will use
   CREATE2 for all their hops.

 * ADD a new section on enumerating bridges via the behaviours
   inherent to bridge reachability testing.

 * REMOVE open question (from the very end of the proposal) regarding
   whether the standard guard selection algorithms are adequate.  They
   are.  (Even if they are convoluted and overly-complicated.)

 * CHANGE updated date to today.
 * REMOVE paragraphs detailing proposals #197 and #199 from the "stalled
   proposals" section.
 * ADD proposal #253 to the "proposals to take another look at" section.
 * CHANGE the "since last time" section to reflect above changes.

The state of the art has advanced so much since this was written; this
simply wouldn't get done this way in a modern design.