create new job (returns uuid)
update job state (running, finished, ...)
create and update steps (set to finished, duration, outcome)

creating a new step marks the previous one as succesfully completed (if not alredy marked as finished)
    so does setting the job to finished
on top of setting the job's outcome to a specific value, there is _COMPUTED_ special value that inferres the outcome based on the steps

Does it make sense to have more than COMPLETED and FAILED outcomes initially?
Should status and outcome be separated, as they are now (not in DB, but in the user-facing objects)?
    My idea here is that status would be able to be SCHEDULED and RUNNING as now, but instead of FINISHED it would return the outcome value (COMPLETED, FAILED, ...)
    The current state needs you to 'care about' two different values, but the more I think about it, the less sense it makes to have that separation
Does it make sense to store the item and/or item_type? I see some value there to be able to search for "did any jobs run on this stuff, without reporting results" so this is why I kept it so far. But I guess we can revisit this once we decide on the way to solve passing 'random arguments' to libtaskotron.

API documentation
search over jobs (name, item, state, ...)