Refactor ContentDecision to be used consistently

[eviljeff]

Fixes: mozilla/addons#15220

Description

Significant refactoring of how we create ContentDecisions, and how they're "processed", so we can a) use a single workflow for decisions that originate in Cinder and the reviewer tools.

With this patch we no longer call the task with an activity log and create the ContentDecision later - instead we create the ContentDecision in record_decision and pass that id.

The main changes are

• in abuse/models.py
  • CinderJob.resolve_job is no more - all the code is in ContentDecision;
  • the cinder functionality in notify_reviewer_decision is now in report_to_cinder;
  • and execute_action_and_notify - nee process_action - can handle decisions from anywhere
• and then in reviewers/utils
  • record_decision creates the ContentDecision and then creates the activity log before triggering the task

Context

One of the blockers to be able to hold and release decisions made via the reviewer tools. Also contributes to us having less separate code-paths we have to maintain.

Testing

Mainly these changes impact reviewer tools originated decisions, so to focus on that:

• reject a version in the reviewer tools
• see the developer receives the expected email notification, that includes the version numbers + review text (the policy text from the policies should not be repeated in the email text)
  • (more advanced case: delay reject and reject multiple versions instead)
• repeat while resolving a cinder job at the same time
  • to get a CinderJob, report an add-on for abuse inside the add-on, as a policy violation
  • the outstanding job should create a NeedsHumanReview that causes the add-on to be in the review queue
• the add-on should be cleared from the queue after the review
• abuse reporter should get an email (as before) too

To verify processing decisions originated in Cinder hasn't regressed:

• report an add-on for abuse on the AMO detail page or under another policy so it appears in the Cinder queue for extension abuse
• make a decision to disable the add-on in Cinder
• replay that decision locally
• check the add-on was disabled, and the emails were sent to the reporter and developer as now.

Checklist

• Add #ISSUENUM at the top of your PR to an existing open issue in the mozilla/addons repository.
• Successfully verified the change locally.
• The change is covered by automated tests, or otherwise indicated why doing so is unnecessary/impossible.
• Add before and after screenshots (Only for changes that impact the UI).
• Add or update relevant docs reflecting the changes made.

[eviljeff]

This is one part I'm not completely happy with: it works, but ends up creating separate decisions - and sending separate emails - for the different users and activity types. I feel at least the different users could be combined - it's just whether it's important enough to be fixed now or as a follow-up.