Process content review decisions without a known job

[eviljeff]

Fixes: mozilla/addons#16155

Description

Change the webhook handling code to not baulk at an unknown cinder job uuid, but to create a decision anyway, if the entity exists.

Context

Was originally going to be the PR for mozilla/addons#15973 but the webhook changes turned out to be substantial. (They can be reused for mozilla/addons#16052 - there's nothing that actually restricts the changes to just the content review queue)

The restriction that the created date match the add-on wasn't specified anywhere, it was just an idea I had to avoid too much cross-contamination on dev and stage. Maybe it's unnecessary? (it shouldn't happen on prod anyway)

Testing

• Trigger a content review somehow (submit a new add-on; edit the name/summary of an existing add-on)
• in Cinder, take an action on the job for that add-on id (either approve or the takedown policy available - the one that has the reject listing content action).
• copy the payload from cinder into tmp/payload.json; replay locally with ./manage.py fake_cinder_webhook
• if you chose the takedown policy the add-on will now have a status of REJECTED; if you chose Approve then you'll need to use django shell to see that it's AddonApprovalsCounter.content_review_status is PASS.

If you chose the takedown policy you can also try the request new review button - a job should be opened, and if you approve the content in Cinder (and replay) it will change the add-on listing back to the previous state.

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.