Make bridge clients download bridge descriptors immediately

The download schedule tells Tor to wait 15 minutes before downloading
bridge descriptors. But 17750 made Tor ignore that and start immediately.
Since we fixed 17750, Tor waits 15 minutes for bridge client bootstrap,
like the schedule says.

This fixes the download schedule to start immediately, and to try each
bridge 3 times in the first 30 seconds. This should make bridge bootstraps
more reliable.

Fixes 23347.

changes/bug23347

@@ -0,0 +1,6 @@
+  o Minor bug fixes (bridge client bootstrap):
+    - Make bridge clients download bridge descriptors immediately.
+      The bridge schedules were never correct, but we didn't realise until
+      the fix for 17750 made bridge clients hang for 15 minutes before
+      bootstrapping.
+      Fixes bug 23347. Not in any released version of Tor.

doc/tor.1.txt

@@ -2475,7 +2475,7 @@ The following options are used for running a testing Tor network.
        TestingClientDownloadSchedule 0, 0, 5, 10, 15, 20, 30, 60
        TestingServerConsensusDownloadSchedule 0, 0, 5, 10, 15, 20, 30, 60
        TestingClientConsensusDownloadSchedule 0, 0, 5, 10, 15, 20, 30, 60
-       TestingBridgeDownloadSchedule 60, 30, 30, 60
+       TestingBridgeDownloadSchedule 0, 5, 10, 30, 60
        TestingClientMaxIntervalWithoutRequest 5 seconds
        TestingDirConnectionMaxStall 30 seconds
        TestingConsensusMaxDownloadTries 80
@@ -2541,7 +2541,8 @@ The following options are used for running a testing Tor network.
 
 [[TestingBridgeDownloadSchedule]] **TestingBridgeDownloadSchedule** __N__,__N__,__...__::
     Schedule for when clients should download bridge descriptors. Changing this
-    requires that **TestingTorNetwork** is set. (Default: 1200, 900, 900, 3600)
+    requires that **TestingTorNetwork** is set. (Default: 0, 8, 3600, 10800,
+    25200, 54000, 111600, 262800)
 
 [[TestingClientMaxIntervalWithoutRequest]] **TestingClientMaxIntervalWithoutRequest** __N__ **seconds**|**minutes**::
     When directory clients have only a few descriptors to request, they batch

src/or/bridges.c

@@ -632,7 +632,9 @@ fetch_bridge_descriptors(const or_options_t *options, time_t now)
         continue;
       }
 
-      /* schedule another fetch as if this one will fail, in case it does */
+      /* schedule another fetch as if this one will fail, in case it does
+       * (we can't increment after a failure, because sometimes we use the
+       * bridge authority, and sometimes we use the bridge direct) */
       download_status_failed(&bridge->fetch_status, 0);
 
       can_use_bridge_authority = !tor_digest_is_zero(bridge->identity) &&
@@ -787,8 +789,13 @@ learned_bridge_descriptor(routerinfo_t *ri, int from_cache)
     if (bridge) { /* if we actually want to use this one */
       node_t *node;
       /* it's here; schedule its re-fetch for a long time from now. */
-      if (!from_cache)
+      if (!from_cache) {
         download_status_reset(&bridge->fetch_status);
+        /* We have two quick attempts in the bridge schedule, and then slow
+         * ones */
+        download_status_failed(&bridge->fetch_status, 0);
+        download_status_failed(&bridge->fetch_status, 0);
+      }
 
       node = node_get_mutable_by_id(ri->cache_info.identity_digest);
       tor_assert(node);

src/or/config.c

@@ -586,7 +586,10 @@ static config_var_t option_vars_[] = {
    * blackholed. Clients will try 3 directories simultaneously.
    * (Relays never use simultaneous connections.) */
   V(ClientBootstrapConsensusMaxInProgressTries, UINT, "3"),
-  V(TestingBridgeDownloadSchedule, CSV_INTERVAL, "1200, 900, 900, 3600"),
+  /* The bridge code relies on the third item in this schedule being slow
+   * (~ 1 consensus interval) */
+  V(TestingBridgeDownloadSchedule, CSV_INTERVAL,
+    "0, 8, 3600, 10800, 25200, 54000, 111600, 262800"),
   V(TestingClientMaxIntervalWithoutRequest, INTERVAL, "10 minutes"),
   V(TestingDirConnectionMaxStall, INTERVAL, "5 minutes"),
   V(TestingConsensusMaxDownloadTries, UINT, "8"),
@@ -648,7 +651,9 @@ static const config_var_t testing_tor_network_defaults[] = {
                                  "15, 20, 30, 60"),
   V(TestingClientConsensusDownloadSchedule, CSV_INTERVAL, "0, 0, 5, 10, "
                                  "15, 20, 30, 60"),
-  V(TestingBridgeDownloadSchedule, CSV_INTERVAL, "60, 30, 30, 60"),
+  /* The bridge code relies on the third item in this schedule being slow
+   * (~ 1 consensus interval) */
+  V(TestingBridgeDownloadSchedule, CSV_INTERVAL, "0, 5, 10, 30, 60"),
   V(TestingClientMaxIntervalWithoutRequest, INTERVAL, "5 seconds"),
   V(TestingDirConnectionMaxStall, INTERVAL, "30 seconds"),
   V(TestingConsensusMaxDownloadTries, UINT, "80"),

src/or/directory.c

@@ -5663,8 +5663,8 @@ download_status_get_initial_delay_from_now(const download_status_t *dls)
  * (We find the zeroth element of the download schedule, and set
  * next_attempt_at to be the appropriate offset from 'now'. In most
  * cases this means setting it to 'now', so the item will be immediately
- * downloadable; in the case of bridge descriptors, the zeroth element
- * is an hour from now.) */
+ * downloadable; when using authorities with fallbacks, there is a few seconds'
+ * delay.) */
 void
 download_status_reset(download_status_t *dls)
 {