Redesign BridgeDB's class inheritance to make designing new distributors easier

Everything is piled in lib/bridgedb/Dist.py right now, with a lack of organisation and documentation, making it rather overwhelming for others to design new distributors.

Here are some of the things which should be revised:

1. Distributor Class Interface The class inheritance design of current distributors is all within one file and doesn't have any clear indication of what methods/attributes are necessary to create a new distributor. There should probably be a zope.interface.Interface class so that implementations of new distributors can be easily checked to see that they meet the specification.

2. Distributor Class Inheritance The current Distributor "base class" in lib/bridgedb/Dist.py inherits from bridgedb.Bridges.BridgeHolder which is one of the hashring classes. I've never looked into why this is done, but these should likely be distinct and separate classes. Either way the code in lib/bridgedb/Bridges.py is a complete mess as well, and will likely need some cleanup.

3. Hide Database Transactions There should probably be some sort of getBridgesFromDBManager() method for distributors, so that they can send a bridgedb.bridgerequest.BridgeRequest (or subclass) to a database manager.

   • This method should expect to interact with a system, called the DatabaseManager, that doesn't exist yet because I'm currently building it, and also expect to receive some JSON in return which contains appropriate bridges for the client's request.
   • This is so that the DatabaseManager can handle BridgeRequest queuing and database transactions, and the distributor can continue going about its business without having to worry about interacting with hashrings or databases or any of the complicated backend stuff.
   • This should permit the distributors to be run in separate processes (or on separate systems), so that they can interact with the DatabaseManager remotely, which will help later when/if we wish to run future distributors with a larger potential attack surface (such as an OTR/XMPP distributor).

There might be more things which will be necessary to change which will be discovered either while hacking on the revision, or while a new distributor is being created through subclassing and working with the new API; these things should be added to this ticket (or a new ticket, then mentioned here).

We might want some sort of DistributorTests mixin class for creating twisted.trial.unittest.TestCases from, so that they have some default checks.