Refactor the update state machine

[bowlofeggs]

Bodhi updates are a state machine, where the current state (such as status: testing, request: None) and inputs (such as karma +1) can cause updates to transition states.

The code that does this is currently scattered around the code (to be fair, mostly in models.py, but there are elements to the state machine found elsewhere), and as a result, it is difficult to modify while being sure you have considered all the code that might need to be touched. For example, @crungehottman is currently modifying the state machine and I'm sure it was difficult to write the code as it was difficult to review (I had a hard time ensuring that all the code that needed to be modified was modified in her pull request.)

It would be good to create a single state transitioning function that accepts inputs and causes whatever state transitions are needed to happen. This way we will have a single place to examine (and test!) when modifying or debugging the state machine.

[jeremycline]

Just to clarify, the PR you're referring to is #1678 correct?

That set_request function definitely looks multi-purpose and scary. Consolidating all the state transition logic into a single function sounds good to me.

I'm not sure if it would make it more or less comprehensible to move the code that reacts to state transitions into a set of SQLAlchemy event listeners (one for each state), but that might be a good place for the code in that function and any others participating in the state transitioning.

[bowlofeggs]

@jeremycline yeah that's the one. I think it would have been much easier to achieve what she's doing if we had a clean, centralized state machine definition.

I had actually been thinking the same thing about using SQLAlchemy event listeners, so state transitions can happen automatically and in the background. That way, things that change the state of an update also wouldn't have to remember to call a state transition handler - it could happen automatically.