Add triggers for new addons and metadata change to submit to Cinder

[eviljeff]

Fixes: mozilla/addons#15972

Description

Adds a trigger in watch_status to send an event to Cinder to carry about a content review the first time the addon status is valid; and adds further triggers in the two places you can edit metadata, and we reset content review status already.

Context

If you process the job in Cinder, the payload won't be accepted at this point, because it will refer to a job we don't know about (we can address the changes to the webhook handler in mozilla/addons#15973).

We don't make any attempt to stop the existing content review queue in reviewer tools from being populated with the add-ons too (I did investigate this, but it was non-trivial because it's all queries based on statuses, so we have to duplicate a bunch of the statuses); and if an add-on is content reviewed in the reviewer tools it won't remove the job from the Cinder queue, so it would be reviewed twice, possibly with different actions (this is particularly difficult to address, because we don't know about the job). If we don't want to support both Cinder and reviewer tools being used simultaneously (and in mozilla/addons#16106 we concluded we don't), and are planning to remove the reviewer tools content review queue anyway, this is fine.

Testing

• enable content-review-in-cinder waffle switch (you might need to manually run migrate)
• submit a new add-on via devhub. At the details step, before submitting, check if there is a job in Cinder in the listing content queue for your addon id. If so, close it, to have a clean testing environment.
• After you go past the details step a task should fire which leads to a job in Cinder for content review (actually the first point the status changes to NOMINATED) - see the job. Further testing variations are:
  • via addon submission api, or
  • if the first version was unlisted, then when a listed version was submitted that triggers the add-on to become NOMINATED
• make a change to the add-ons name or summary in devhub edit. See a job in Cinder is created (or a new "report" on an existing job if the add-on is already in the listing content queue. The new ContentChange relationship will only show up in the addon investigate page, not the current job - known Cinder problem). Alternatively:
  • via the addon submission api
• to test the content rejection scenario, first close the open job in Cinder, then reject the listing content via reviewer tools (because we can't process the payload yet, as mentioned above)
• make a change to the add-ons name or summary. See a new ContentChange relationship is in Cinder investigate addon page, but a new job is not opened.
• request a new content review in devhub/api
• see a job is opened for the content review in Cinder.

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]

note, create_defaults is a django52 addition. If we decide to rollback to django42 it will need rewriting first.