reassess minimum-dir-info when a bridge fails

When we try to fetch a bridge descriptor and we fail, we mark
the guard as failed, but we never scheduled a re-compute for
router_have_minimum_dir_info().

So if we had already decided we needed to wait for this new descriptor,
we would just wait forever -- even if, counterintuitively, *losing* the
bridge is just what we need to *resume* using the network, if we had it
in state GUARD_REACHABLE_MAYBE and we were stalling to learn this outcome.

See bug 40396 for more details.

changes/bug40396

@@ -0,0 +1,10 @@
+  o Major bugfixes (bridges):
+    - Make Tor work reliably again when you have multiple bridges
+      configured and one or more of them are unreachable. The problem
+      came because we require that we have bridge descriptors for both
+      of our first two bridges (else we refuse to try to connect), but
+      in some cases we would wait three hours before trying to fetch
+      these missing descriptors, and/or never recover when we do try
+      to fetch them. Fixes bugs 40396 and 40495; bugfix on 0.3.0.5-rc
+      and 0.3.2.1-alpha.
+

src/feature/client/entrynodes.c

@@ -2271,6 +2271,13 @@ entry_guards_note_guard_failure(guard_selection_t *gs,
            guard->is_primary?"primary ":"",
            guard->confirmed_idx>=0?"confirmed ":"",
            entry_guard_describe(guard));
+
+  /* Schedule a re-assessment of whether we have enough dir info to
+   * use the network. Counterintuitively, *losing* a bridge might actually
+   * be just what we need to *resume* using the network, if we had it in
+   * state GUARD_REACHABLE_MAYBE and we were stalling to learn this
+   * outcome. See bug 40396 for more details. */
+  router_dir_info_changed();
 }
 
 /**