add support for Approve marking listing content as approved

[eviljeff]

Fixes: mozilla/addons#15984

Description

Expands the Approve action to do as the naming implies, to approve the listing content (for add-ons). If the add-on is STATUS_REJECTED, approving the content will restore the addon status too (and send an email to the developer informing them).

Context

Even though for content review there won't usually be any abuse reports resolved, the code (and tests) are written to support resolving an abuse report at the same time (which might be useful for mozilla/addons#15969)

Testing

Similar to #24308, this is mainly expected to be used with content review in Cinder, but that doesn't exist yet - though the Approve policy does exist already - so easiest way is to use the abuse report flow:

For content review where the add-on isn't rejected (normal case):

• identify an add-on that hasn't already been content reviewed (or delete its AddonApprovalsCounter instance)
• report add-on for abuse
• in Cinder make a decision to Approve the add-on
• replay the webhook payload with ./manage.py fake_cinder_webhook
  • the add-on should now be marked as content approved (not in the reviewer tools content review queue)
  • no email should have gone out to the developer

Then for content review where the add-on is rejected (i.e. the developer requested another review):

• either:
  • go through the reject listing steps (report for abuse; edit/identify a policy so it has amo-reject-listing-content as the action; replay webhook),
  • or just update it's AddonApprovalsCounter so last_content_review_pass = False and the status is STATUS_REJECTED
• report the add-on for abuse
• in Cinder make a decision to Approve the add-on again
• replay the webhook payload with ./manage.py fake_cinder_webhook
  • the add-on should now be marked as content approved, and the status restored to APPROVED (or whatever the previous status was before)
  • an email should have gone out to the developer informing them we restored their listing

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]

FYI:

Then for content review where the add-on is rejected (i.e. the developer requested another review):

For this scenario, I think you have to report the content first, then reject it, otherwise the add-on won't be public, so even if you were to directly go the report feedback page, you wouldn't be able to report it for its listing contents... That makes testing this via Cinder super confusing.

[eviljeff]

otherwise the add-on won't be public, so even if you were to directly go the report feedback page, you wouldn't be able to report it for its listing contents...

You should be able to report it a non-public add-on from the feedback url directly http://olympia.test/firefox/feedback/addon/<addon-slug>/, and if you were logged in with permissions, the link would still be on the detail page. (I can't remember which way around I actually did it)

[diox]

Yeah I saw that but it won't allow you to select the listing as the place of the violation since there is no longer a public listing. I wasn't sure of where the report would end up so I swapped the ordering of the steps to be sure.