param-spec: Document the vanguard params.

See merge request !258

prop340: clarify SENDME window accounting

See merge request !265

prop340: Expand on why we don't allow DATA fragmentation

See merge request !264

Slight clarifications about hsv3 relay crypto

See merge request !261

I was going to propose allowing DATA fragmentation, but I think I've
talked myself out of it. I think it'll be useful to have a record of
this line of thought for future reference.

cert-spec: Put backticks around SIGNATURE

See merge request !263

See !259

Rename "text vectors" to "test vectors" for correctness.

See merge request !260

There was a missing link at one point, and another point where we
should have said what cryptography we were using.

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

Prompted by !258 (comment 3011734)

This documents the 3 [vanguard-related parameters] currently supported
by C Tor.

Note: Arti will support full vanguards too, so we may want to also add
parameters for configuring the third layer of guards.

[vanguard-related parameters]: https://gitlab.torproject.org/tpo/core/tor/-/blob/2d19050ef9f2612aab826fe2973dd9fab1df8438/src/feature/client/entrynodes.c#L4126-4159

Clarifications about INTRODUCE1/2 extensions

See merge request !255

Prop#349: Command state validation

See merge request !257

Completely ignore unknown hspow-params

Closes #256

See merge request !256

hspow: Clarifications to scheme and descriptor Item

See merge request !254

I got the answer to this question from
  proposals/324-rtt-congestion-control.txt

(This thing should have a proper identifier, not merely a descriptive
phrase, but that may be controversial.)

This sentence seems stray in this section.  The information is alreayd
present with the wording

  The same rules for multiplicity, ordering, and handling unknown types
  apply to the extension fields here as described \[EST_INTRO\] above.

which appears earlier, for each of the two sections.

The text uses "scheme" and "version" a couple of times.  The formal
protocol says "type".  The terminology should be consistent.  IMO
"scheme" is the best word to use.  "version" is particularly bad.

Change all references to "type" and "version" to "scheme".

Revise the INTRO1_POW_EXT section

See merge request !253

There were two different versions of this description in the doc, and
they were both wrong in different ways. One was newer and implied the
extension was encoded outside the encrypted section (it's inside). The
other was older and had some outdated references and recommendations
from when this was still a proposal, but it was in the correct location.

I consolidated the two and made the correct location of the extension
explicit.

Proposal 340 clarifications

See merge request !252

Replace "payload" with "body"

See merge request !248

Clarify rend-point behavior with relay cells

Closes #254

See merge request !250

Beautify the table of relay commands

See merge request !249