Improve relaunch logic for failed rendezvous circuits
When a hidden service fails its rendezvous circuits (maybe because it's too overworked, or maybe its guard is overwhelmed) it currently retries up to MAX_REND_FAILURES times (this used to be 8 but #11447 (moved) will change it to 1).
When the client notices the failure, it will also retry every 2 seconds or so, subject to normal circuit_expire_building() expiry.
In the future, to reduce the computational costs of hidden services, we could push the retry logic solely to the clients. At that point the client should ensure that the rendezvous circuit retries enough time to be correct.
Furthermore, currently, when the client notices a rend circ failure, it will establish a new rendezvous point and send a new INTRODUCE1 cell to the IP. Maybe this can be optimized, and have the client keep the same rendezvous point for a while and just send more introductions. After a few more failed introductions, the client should switch rendezvous point as well.