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.

[diox]

Don't love this... It's fairly fragile. Not that much better but could we use human_review instead ? reviewtype is kinda obsolete these days...

At the minimum add a comment in ReviewBase.log_action() to make sure we continue setting this in the future...

[eviljeff]

Afaik we can't use human_review because we also need it for auto (delayed) rejections, where it human_review=False. So it was either add a new property to add the details blob, or hijack reviewtype.

It should go away with https://mozilla-hub.atlassian.net/browse/AMOENG-672 though.

[eviljeff]

mmm, forgot the comment. I'll add it with mozilla/addons#1982