This commit does not change the implementation of any function: it
only moves code and adds new includes as necessary.  Part of #23149.

"ours" merge to avoid version bump.

David Goulet authored Aug 24, 2017 and Nick Mathewson committed Sep 05, 2017

Fixes #23319

Cherry-picked from master; bug not in any released Tor.

"ours" merge to avoid version bump

David Goulet authored Aug 25, 2017 and Nick Mathewson committed Sep 05, 2017

The service needs the latest SRV and set of relays for the best accurate
hashring to upload its descriptor to so it needs a live consensus thus don't
do anything until we have it.

Fixes #23331

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

David Goulet authored Aug 30, 2017 and Nick Mathewson committed Sep 04, 2017

When merging #20657, somehow hs_service_dir_info_changed() became unused
leading to not use the re-upload to HSDir when we were missing information
feature.

Turns out that it is not possible to pick an HSDir with a missing descriptor
because in order to compute the HSDir index, the descriptor is mandatory to
have so we can know its position on the hashring.

This commit removes that dead feature and fix the
hs_service_dir_info_changed() not being used.

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

Based on questions and comments from dgoulet, I've tried to fill
in the reasoning about why these functions work in the way that they
do, so that it will be easier for future programmers to understand
why this code exists and works the way it does.

The function was never returning an error code on failure to parse the
OutboundAddress* options.

In the process, it was making our test_options_validate__outbound_addresses()
not test the right thing.

Fixes #23366

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

 * THANKS TO Henry de Valence for review.

This fixes a serious bug in our hsdir set change logic:

We used to add nodes in the list of previous hsdirs everytime we
uploaded to a new hsdir and we only cleared the list when we built a new
descriptor. This means that our prev_hsdirs list could end up with 7
hsdirs, if for some reason we ended up uploading our desc to 7 hsdirs
before rebuilding our descriptor (e.g. this can happen if the set of
hsdirs changed).

After our previous hdsir set had 7 nodes, then our old algorithm would
always think that the set has changed since it was comparing a smartlist
with 7 elements against a smartlist with 6 elements.

This commit fixes this bug, by clearning the prev_hsdirs list before we
upload to all hsdirs. This makes sure that our prev_hsdirs list always
contains the latest hsdirs!

Our logic for detecting hsdir set changes was needlessly compicated: we
had to sort smartlists and compare them.

Instead, we can simplify things by employing the following logic:
"We should reupload our descriptor if the latest HSDir set contains
nodes that were not previously there"

We want to have tests with big hash rings so let's make it an one-liner
to add nodes.

 * FIXES #22818

Called from main.c, the function for now purges the hidden service directory
request cache.

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

Since we can't be sure that we can unlink enough files on windows
here, let's let the number of permitted entries grow huge if it
really must.

We do this by letting the storagedir hold lots of entries, but still
trying to keep the number of entries under the configured limit.  We
also have to tell consdiffmgr not to freak out if it can't actually
remove enough entries.

Part of a fix for bug 22752

Part of a fix for bug 22752: We can't unlink these because Windows
doesn't allow you to unlink an in-use file.