Create a DatabaseManager for interacting with BridgeDB's database backends

[isis]

We need a DatabaseManager which will handle receiving BridgeRequests from BridgeDB's distributors, and will ​queue these requests as transactions with the backend databases.

The distributors are going to use a common method (just call it getBridgesFromDBManager() for now) to request Bridges from the DatabaseManager, and they will expect to receive some relatively well-supported, simple, serialised format (probably JSON) in return.

1. The Easy Way The easier way to do this would be to not really actually truly make a for-reals ORM, and simply expect to be interacting with a NOSQLly CouchDB backend ​as described in proposal #226. CouchDB documents are JSON anyway, so this is super easy. If we go this route, we'll need some code to convert the old SQLly stuff to the new NOSQLly format.

2. The Masochistic Way The harder, but possibly better in the long run (should we ever decide to stop using NOSQL/OODBMSs), way to do this would be to write a true ORM/RDBMS which can work with either system.

This databases which this system will interact with will be used for storing complex/referential/self-referential/recursive datatypes, such as bridgedb.Bridges.Bridges and structures for storing data about blocking events for bridges (including timestamps, discovery method, and country code of the block, etc.) as defined ​in Section 1.b. of proposal #226.

[isis]

I've been working on this over the past few weeks. A prototype of this work is available in my feature/12030-database-manager branch, however it is not yet ready for merge.

[isis]

Adding to my august tickets.

[MikiMix]

Replying to isis:

Adding to my august tickets.

[gaba]

Adding the keyword to mark everything that didn't fit into the time for sponsor 19.

[gaba]

Remove sponsor 19 and add a keyword ex-sponsor19 to mark all the tickets that could have been in the scope of the sponsor.