Fix bug when parsing bwhist with unexpected Interval

Previously, our state parsing code would fail to parse a bwhist
correctly if the Interval was anything other than the default
hardcoded 15 minutes.  This change makes the parsing less incorrect,
though the resulting history array might get strange values in it if
the intervals don't match the one we're using.  (That is, if stuff was
generated in 15 minute intervals, and we read it into an array that
expects 30 minute intervals, we're fine, since values can be combined
pairwise.  But if we generate data at 30 minute intervals and read it
into 15 minute intervals, alternating buckets will be empty.)

Bugfix on 0.1.1.11-alpha.

changes/1863_bwhist

@@ -0,0 +1,5 @@
+  o Minor bugfixes
+    - Fix a bug in banwidth history state parsing that could have been
+      triggered if a future version of Tor ever changed the timing
+      granularity at which bandwidth history is measured.  Bugfix on
+      Tor 0.1.1.11-alpha.

src/or/rephist.c

@@ -1165,6 +1165,8 @@ rep_hist_load_mtbf_data(time_t now)
  * totals? */
 #define NUM_SECS_ROLLING_MEASURE 10
 /** How large are the intervals for which we track and report bandwidth use? */
+/* XXXX Watch out! Before Tor 0.2.2.21-alpha, using any other value here would
+ * generate an unparseable state file. */
 #define NUM_SECS_BW_SUM_INTERVAL (15*60)
 /** How far in the past do we remember and publish bandwidth use? */
 #define NUM_SECS_BW_SUM_IS_VALID (24*60*60)
@@ -1577,7 +1579,9 @@ rep_hist_load_bwhist_state_section(bw_array_t *b,
         }
         if (start < now) {
           add_obs(b, start, v);
-          start += NUM_SECS_BW_SUM_INTERVAL;
+          /* This will result in some fairly choppy history if s_interval
+           * is notthe same as NUM_SECS_BW_SUM_INTERVAL. XXXX */
+          start += s_interval;
         }
     } SMARTLIST_FOREACH_END(cp);
   }