Add Content rejected state to possible add-on statuses; and ContentActionRejectListingContent

[eviljeff]

Fixes: mozilla/addons#15985 and also fixes mozilla/addons#15983

Description

Minimally implements the concept of a listing rejection, and adds a ContentAction - that would be assigned to appropriate policies - that sets it, and reverts it on appeal.

Context

An initial outstanding content review wouldn't affect the add-on status, because it's silent (and could occur under any add-on status), but once the content is rejected, STATUS_REJECTED means the add-on isn't public, and the status becomes sticky (developers can't get around it by deleting versions, etc). Only an appeal (supported), or a new content review that has an approve decision (not implemented yet), can reverse the rejection and move the add-on back to an appropriate status (be it approved, nominated, or otherwise).

I initially implemented this entirely with STATUS_REJECTED, but if we want add-on disables, and the reverse, to still work there needs to be a flag that indicates the add-on has a failed content review so the status can be recovered. It seemed like AddonApprovalsCounter was a good enough place as it was already tracking dates for successful content review... but now's the time to suggest a better location for the field.

Testing

• This is mainly expected to be used with content review in Cinder, but that doesn't exist yet and none of the policies have been updated, so easiest way is to use the abuse report flow and edit the webhook, i.e.
  • report add-on for abuse
  • in Cinder make a decision the add-on is against an acceptable use policy
  • copy the webhook payload from cinder and edit it to change amo-disable-addon to amo-reject-listing-content in both places in the json
  • replay that with ./manage.py fake_cinder_webhook
  • (if you chose a recommended, etc, add-on the decision will be held for 2nd level approval - proceed with the action)
• see the add-on's listing is non-public on frontend
• see the status is correct in devhub and reviewer tools
• force disable the add-on in reviewer tools -> works, is now Disabled by Mozilla status
• force enable the add-on in reviewer tools -> returns to Rejected status rather than Incomplete or Approved
• approving/rejecting any versions doesn't change the status from Rejected
• use the appeal link in the email we sent and accept the appeal via Cinder
• copy the webhook payload again - also changing the action in all places - and reply
• add-on status has returned to approved, or whatever it should be based on the statuses of the approved versions

Checklist

• Add #ISSUENUM at the top of your PR to an existing open issue in the mozilla/addons repository.
• Successfully verified the change locally.
• [ x 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.