Relays don't actually notice bandwidth changes for a day

Summary:

The current Tor has a bug where it assesses what "bandwidth observed" to put in its descriptor using only the bandwidth it saw itself do yesterday or earlier. This bug is especially sad for testing tor networks like chutney because 24 hours ago is a long time for a chutney network; but it is also sad for relays bootstrapping in general because they don't behave in the way we thought they did.

Background:

Relays self-assess their own observed bandwidth by looking at the highest 10-second burst they've seen themselves do in either direction and picking the smaller of these two bursts. Specifically, they keep a set of previous largest bursts for past epochs, and a running count of the largest burst so far in the current epoch. When an epoch ends, they push all the epoch counts back one and store the current largest burst as the most recent epoch. When they want to know what number to put in the descriptor, they look for the highest burst among the past epochs, and they don't look at the current running largest.

At the dawn of time (Tor 0.0.8pre1 through Tor 0.2.6.3-alpha), the epochs lasted 15 minutes, so you'd need to wait up to 15 minutes before the current running total got stored and then counted for a new bandwidth estimate.

But then in Tor 0.2.6.3-alpha we moved that "15 minutes" up to "4 hours" (#13988 (closed), git commit 6830667d), and then in Tor 0.3.2.6-alpha we moved from 4 hours to 24 hours (#23856 (closed), git commit 8be50ca3). That's when things went bad for the relay capacity estimation: we continued only asking ourselves about past epochs, even though the past epochs got farther and farther in the past.

This feature is now at odds with, for example, the feature in check_descriptor_bandwidth_changed() that decides that big bandwidth shifts are only a good reason to publish a new descriptor if our uptime is less than 24 hours.