delegate reject actions to ContentActions too

[eviljeff]

Fixes: mozilla/addons#15306

Depends on #23004 & needs rebasing after that is merged.

Description

Implements the last remaining actions that could need a hold for 2nd level approval - version rejections.

Context

To ease implementation, I've focused on the simple case - the initial rejection of one or more versions - so ignored auto rejections and rejections that happen via blocks (and renamed the existing reject_multiple_versions function). Auto rejections don't need another hold because it was already considered when the initial decision was made; blocks have their own hold criteria. Follow-up work would be to continue migrating the remaining code that changes addon/version states in the reviewer tools to their equivalent ContentAction

Testing

Similarly to #15306, the change is how the action ends up being processed in the reviewer tools, but this time for all the reject actions:

• For a "normal" add-on, select reject action from reviewer tools, and choose a reason.
• verify that the version was disabled; and the email we send out contains the reason text
• check the activity log created is linked to the addon, the version rejected, decision, policy, and reason.

Repeat with an add-on that would be considered high impact - e.g. a Recommended or Notable add-on.

• select reject from the reviewer tools, etc.
• verify that the version was not disabled, and the review history includes that the action was held. (no email to developer either)
• Go to 2nd level approval queue and release the hold - proceed with the action.
• verify that the version was disabled; and the email we send out contains the reason text
• check the activity log created is linked to the addon, version rejected, decision, policy, and reason.

This can be further repeated with multiple version rejection; delayed rejections; and content rejections - they should all work as before when the add-on isn't high impact, but be held for review if the add-on is.

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]

fwiw, I did consider using separate Action classes ("ContentActionRejectContent" and "ContentActionRejectContentDelayed"), but it's the same actual outcome, with the emails sent in either case so didn't seem worth the extra complexity - especially as content reviews are being changed soon(?).

At that point we may want a different ContentAction class - and perhaps set AMO_DISABLE_ADDON instead as the cinder action as it's more what the outcome is (the listing being removed) than a version rejection(?)

[diox]

It won't be shown to developers (it's an admin event), so it doesn't need to be translated. Same for the others below (and also REQUEST_LEGAL above if you want to do a drive-by)

[diox]

Should this be part of the ContentAction ? It feels like a consequence of the action, something that we wouldn't do if the action is "cancelled" after being held up for approval.

[diox]

Doesn't block merging though.

[eviljeff]

My thinking was that in either case we'd want to stop any further auto approvals. It also prevents any approvals while the rejection is held.

[diox]

mmm yeah preventing any approvals while the rejection is held certainly makes sense.