These changes make sure that the errors conform to our preferred
style, and include a description of what exactly we were doing when
something went wrong.
According to doc/Errors.md, and in keeping with current best
practices, we should not include display an error's `source()` as
part of that error's display method. Instead, we should let the
caller decide to call source() and display that error in turn.
Part of #323.
At the site of modify_hop, we now have a comment explaining the
internal-error issue.
To make the internal error less likely, we lower the modify_hop call
in lib.rs into GuardSet, where it can make sure it's looking at the
same filter as was used to select the guard.
The function name "pick_guard_ext" is not permanent; I'm going to
rename it in the next commit.
Previously, the API said "you need to call this in a loop till it
returns false". We did that in one place, but not another.
With the introduction of filters, forgetting to loop here becomes a
bug: so instead, change the behavior of extend_sample_as_needed so
it handles looping itself.
The fake network we construct for these tests is small in ways that
can sometimes cause weird behavior with guard filters. We fix this
by adjusting the parameters of the guard selection algorithm
accordingly in the tests.
With these new parameters, #491 no longer occurs.
This commit also adds comments to explain why the parameters are set
as they are.
Closes#491.
guard-spec.txt specifies that we have multiple separate samples of
guards that we can use depending on whether the filter is
restrictive or not. Here we implement the rules for switching
between samples.
When we're filtering guards, we have to check whether the filter is
"restrictive": if it forbids most of the guards (by bandwidth), we
keep its guards separated from the main set. If it is
super-restrictive, we also warn.
This functionality is specified in guard-spec.txt.
Since a guard can have a bunch of addresses, and the guard is
permitted if any one of those addresses is permitted, then we might
decide to use a guard with some non-permitted addresses. Thus, we
need to filter those addresses before returning the view of the
guard as a FirstHop.