Make BridgeDB and bridge authority more resilient

We should explore options to decentralise BridgeDB and/or our bridge authority.

Trac:
Parent Ticket: #31281 (moved)

added component::circumvention/bridgedb parent::31281 points::10 priority::medium s30-o24a5 severity::normal sponsor::30-must status::new type::task labels

gman999 into the cc

Trac:
Cc: phw to phw, gman999, cohosh

gman999 thought about setting up two bridge authorities behind a single, virtual IP address. This will make our bridge authority more resistant to hardware failure because if one goes down, there's still the other one that continues operations.

Once set up, both bridge authorities would then separately sync their bridge descriptors to BridgeDB, which expects a single directory of bridge descriptors, so we will either have to 1) teach BridgeDB (and Tor Metrics) how to handle >1 directory of bridge descriptors, or 2) write a tool that takes as input an arbitrary number of directories containing bridge descriptors and then produce as output a combined "view" of these descriptors. We agreed to first take a look at a tool that can combine "views" because it would simplify our processing pipeline and it may be easy to do with Stem.

Trac:
Summary: Look into making BridgeDB more resilient to Make BridgeDB and bridge authority more resilient
Cc: phw, gman999, cohosh to phw

Trac:
Cc: phw to phw, gman999, cohosh

cohosh cc'ing myself on sponsor 30 work

changed time estimate to 80h

mentioned in issue #31281 (moved)

moved to tpo/anti-censorship/bridgedb#31878 (closed)