Use rotating time periods for when each bridge is available for distribution

From #12 (comment 2738534):

I think the original idea was different in that no matter how many email addresses or subnets you have, you still can't learn the bridges we gave out yesterday. That is, the idea was to release a small subset of the total bridge population, and then divide that subset according to the resource-you're-proving constraint.

It could be that this design only works well with a large enough bridge population. For example, let's say we take only 5% of our bridges to give out at a time, and we give them out for a 6 hour interval before moving to the next subset. Then it's 5 days before we get around to offering them again. Those numbers prove the concept ("when you show up and decide to start blocking, people still get several days of use out of the bridges they already have") but they aren't as exciting as an example with an even larger period. If we rotate each 24 hours, then we get a much bigger period of 20 days. And if there's some level of churn in that period, then we're also giving out our fresh bridges in a way that's spread-out into the future, forcing the attacker to sustain the attack (this aspect would work better if the rotation period was more like every hour, so you really do have to hit us every hour or you miss a whole batch).

This general principle is part of what makes Salmon appealing too: "give out bridges to a group of people and then stop giving them out [for a long while] after that".

If we want to mess around with variations on our bridge distribution strategies in order to get more intuition, that sounds great. If we want to wait and "do it right" with Salmon, so long as we know that the first few iterations won't actually be right and we'll be doing that to gain more intuition ;), that sounds great too.

We might want to use that for the telegram bot #77 (closed).