hsclient descriptor download due to IPT nacks
As per #913 (comment 2914467), Arti's current HS client behaviour wrt the service descriptor is:
Ie if it's not expired we assume it's still good to use, even if we are making repeated attempts to connect to the HS - with that descriptor - and they're all failing.
I am informed on IRC that the confirmation there, that this is correct behaviour, was due to a misunderstanding. This behaviour is in fact wrong.
If Arti gets NACKs from the IPTs, it needs to re-download the descriptor. (The service may have been restarted and our descriptor may therefore be out of date.)
In more detail:
- At some threshold of NACKs from IPTs, Arti should re-download the descriptor.
- If it manages to obtain a different descriptor it should try the IPTs in the new descriptor instead.
- "different" and "new" is according to the revision counter in the descriptor.
It's not clear precisely how hard Arti should try to obtain a different descriptor. After all, the service may not have managed to update all the hsdirs. So maybe Arti should try several.
Details of the correct retry algorithm aren't clear. Ideally the overall system would have the following properties:
- Restarting an HS service can be done without generating a persistent loss of availability on clients
- Faulty hsdirs don't cause loss of availability provided there are enough working hsdirs
- Trouble from faulty relays or "bad weather" isn't "magnified" by the hsdir/descriptor system
This ticket represents the required changes to Arti's client behaviour. There are also implications for the work-in-progress server-side work, eg !1429 (merged)