SQLAlchemy migrations, provisioning

[NoiSek]

Didn't intend to, but ended up partially fulfilling #45 on accident instead of actually doing any forum administration features.

Migrates the User, BankAccount, DisplayName, LoginSession, Role, Board, BoardCategory, ForumThread and ForumPost models to SQLAlchemy.

Also adds slight provisioning rework + forum provisioning.

Notes:

• This can't be merged in it's present state, it breaks quite a few things very subtly. Opening it up as an orphan as I need to switch project priorities.
• Did not preserve concept of multiple usernames and a given display_name. Instead, an infinite number of unique display names can exist, but a user's model can only possess one explicitly linked display name.
• Roles remain un-nested from users. There is no real reason for this except that they aren't used often.
• All instance of user 'keys' have been replaced with user ID's.
• Session cookies now rely on auto-generated UUID strings rather than an ndb key
• User ID no longer stored in cookies, must be derived from the session cookie instead.

Registration and login are currently functional. Notifications / Messages, the actual post submission on Forums, and much of the rest of the site are currently non-functional as a side-effect of the partial model migration. (Maybe it's a good idea to keep Notifications / Messages on NDB if they will always be 1:1?)

[coveralls]

Coverage remained the same at 0.0% when pulling 2d7bc1ac49987dddbfee4f4448febd2fab6f77a6 on forum_administration into deba3c997e94345b0b0896266f7ca9c26cf4f763 on master.

[tiffz]

Man, I'm impressed by how quickly you did so much. Thanks for the good work and the writeup. I will write a quick response here before I dive in more into the code.

I think we will probably want to eventually convert Messages and Notifications to ndb as well for these reasons:

• I like to keep things on one system for simplicity if possible.
• Messages could actually benefit from SQL design, I think. For example, compound keys for the UserConversation relationship (compound keys were something I planned on manually implementing in ndb for better lookup efficiency).
• Close enough to a full conversion. Might as well remove a potential vendor locking threat for databases. Though I guess we could always do future migrations.
• I want to just decide on one thing, so we don't want to play "Datastore or SQL?" with every new data model haha.

Though these conversions are certainly not urgent if we can get away with delaying them and have things still function.

As a side note, I would be open to potentially using a hybrid of ndb and SQL in the future if the site is up and running, still using AppEngine, and has problems scaling the database. But this future is not here yet and who knows if it'd ever happen.

[coveralls]

Coverage remained the same at 0.0% when pulling 499636693c4048781eecbba89fe9f68da68272e1 on forum_administration into d275eb846fb36aa389069c086adf3e43291c643b on master.