prop224: Service edge-case where it re-uploads descriptor with same rev counter
There is an edge case where if a service's HSDir connection times out before getting a 200 back, Tor will open a second connection with the same outbuf
as the previous one and retry the upload. See connection_ap_detach_retriable()
which gets called from connection_ap_expire_beginning()
which detaches the stream from the circuit and marks it as pending again.
That's a problem for v3 HSes, since that logic bypasses the HS subsystem and the rev counter does not get incremented for the second upload.
The problem is that if the first connections ends up succeeding (even tho it timed out), the second connection will fail because of rev counter issues.
This is not a reachability issue since one of the two conns will eventually succeed and the right descriptor will be uploaded. However it generates a log_warn on the service-side that might be annoying, and a log_info on the HSdir side.
The right fix here might involve intercepting that retry, and piping it through the HS subsystem. But this will require refactoring.