Rethink shared-random-value agreement
Right now if we fail one particular consensus in a day, we have no shared-random-value for the following day. That approach has turned out, over the past weeks, to be pretty brittle. It's kind of a hassle in general, but we could also look at it as a security issue, e.g. somebody could pick out a relay identity key that targets a particular v3 onion service on a day that runs with the backup srv.
Further, @dgoulet was surprised to learn today that if we don't agree on the new srv, we also stop listing any prev srv. In retrospect it makes sense, because we put all our eggs in the 0utc basket.
So, this ticket is about ideas for improving the robustness of srv generation. Maybe some of the ideas will need proposals, or maybe some of them will just turn out to be bugfixes.