(This is slightly different from recovering from errors in the
middle of a list of mds, since in this case we _can't_ advance to the
next md.)
Also, note that a given branch is probably not reachable.
After changes to the prop339, the domain name in an Address can only be
255 bytes max and can NOT contain nul byte(s).
Unit tests had to be modified to accept this change:
- Centralise msg_ip_address
- Add currently-passing tests for address length
- Test counted address length longer than type wants
Related to #463
Signed-off-by: David Goulet <dgoulet@torproject.org>
Some of our existing code optionally takes a netdir from the
caller. When it doesn't give us one, use the netdir from the
installed NetDirProvider.
(Possibly someday we should remove the NetDir arguments
entirely. I'm deferring that because there are only two APIs
affected, and because making this change would force us to rewrite a
pretty large mess of unit tests.)
Previously it was the job of a task in CircMgr to do this; but we're
going to want to give GuardMgr full access to the latest NetDir for
this, and for other code-simplification reasons.
With this change I'm deprecating a couple of functions in
tor-circmgr. It's no longer necessary for us to have an artificial
external way for you to feed new NetDirs to a circmgr. (I could
just remove them, but I want practice deprecating.)
Our own code is the only stuff that consumes NetDirProvider, and all
the code that consumes it wants it to be Send and Sync.
Making this change avoids our having to define a new function to
upcast Arc<dyn Foo> to Arc<dyn NetDirProvider + Send + Sync>.
This uses some apparently-standard trickery to implement a function
that lets us upcast from Arc<dyn Subtrait> to Arc<dyn Supertrait>.
I considered as alternatives `as_dyn_trait` and `cast_dyn_object`.
Both were nice, but generated a far larger interface than this.
The randomized tests in this crate take a lot of iterations to
converge, so they default to using a deterministic PRNG seed with
few iterations and higher tolerance, and they only randomize the
tests (with more iterations and tighter tolerances) when you
explicitly opt in to randomization.
(If you specify a seed explicitly, you're doing that to reproduce a
randomized case, so we use the same behavior.)
This only affects uses of thread_rng(), and affects them all more or
less indiscriminately. One test does not work with
ARTI_TEST_PRNG=deterministic; the next commit will fix it.
The new `testing_rng()` function is meant as a replacement for
thread_rng() for use in unit tests. By default, it uses a randomly
seeded RNG, but prints the seed before the test so that you can
reproduce any failures that occur. You can override this via the
environment to use a previous seed, or by using a deterministic
seed for all your tests.
Backend for #486.