Betterment/update job

[heemankv]

This PR solves #112.

• Remove update_job_status, update_metadata, update_job_optimistically, post_job_update functions from Database implementation.
• Reimplemented update_job to use JobItemUpdates.
• Provide JobItemUpdates object with all the needed changes only, which get's reflected on the database.

WHY this approach?

• Code had three functions update_job, update_job_status & update_metadata to update job values in database.
• update_job was being passed with the whole jobItem to update, in it's usage it was only changing 2-3 values in the job and not the whole job object, resulting in other values unnecessarily being rewritten. (for eg, same version value is being sent within jobItem, resulting in a pointless rewrite 1 -> 1).
• The above is also why the code had to update version and updated_at fields post these updates, since first the version get's rewritten (1->1) and then it's overwritten to an increased value in post_job_update (1->2).
• update_job_status and update_metadata followed the same trend but only updated individual values.

WHAT now ?

• Trimming the above problem, reinventing update_job seemed the best approach to move forward with.
• Provide a JobItemUpdates object that consist of all the updates that needs to be done to the job in a single query.
• Code doesn't allow updating id and created_at.
• Code implemented only_status and only_metadata to allow for cleaner code for these updates.

[heemankv]

Done with Self Review,
I think we are missing a test case for the new update_job.
WDYT ? @apoorvsadana

[coveralls]

coverage: 67.817% (-0.03%) from 67.848%
when pulling b4e4a4b on betterment/update_job
into ba2aeb8 on main.

[apoorvsadana]

This looks cleaner but I have two issues before the reivew

1. The version shouldn't come from the user. It's a invisible implementation that you don't need to worry about when writing the code. All you should know is that if your job is stale the update won't work.
2. If tomorrow I add a new field to Job and call update_job, it might feel that it would just work but actually I would need to update the logic and handle the if else. Is there a way to catch this silent failure later?

[heemankv]

1. The version shouldn't come from the user. It's a invisible implementation that you don't need to worry about when writing the code. All you should know is that if your job is stale the update won't work.

Updated the logic to don't let parent fn to decide whether to update version or not, it will now always be updated.
Additionally, the same logic is now followed for updated_at.

[ocdbytes]

lgtm