Handle version rejection appeals forwarded to legal

[eviljeff]

Fixes: mozilla/addons#15296

Description

For Cinder decisions, redefines target versions for appeals on VERSION_REJECT_ADDON; corrects the action; and allows the action class to unreject the versions rejected with the appealed decision(s).

Context

The issue identified two problems we had when legal was forwarded an appeal on a version rejection - if we denied the appeal we didn't see it as a the same action and offered another appeal; and if we accepted the appeal there was no way to reverse the rejections.

Testing

follow the STR from the issue basically,

• reject one or more versions in the reviewer tools
• appeal those rejections
• in the reviewer tools forward the appeal job to legal
• in cinder, in the legal queue, deny the appeal by selecting the same policy the original job was rejected for (or any policy that takes down content, really)
• replay the payload for that decision locally
• see the developer gets an email saying we affirmed the original decision

repeat but:

• at the cinder legal queue step, select Approve (or one of the Ignore policies) to accept the appeal
• replay the payload for that decision locally
• see the developer gets an email saying we accepted their appeal
• we have unrejected the 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.
• 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]

this (and below) were drive-by fixes when I was looking into update_status - the arg is supposed to be a Version instance to ignore, so passing self.user was always useless.

[eviljeff]

I figured any time we're updating the status of a file we want to clear status_disabled_reason (?)

[eviljeff]

this (and the change in reviewers/utils.py) are so we save the status before it's rejected, so we're able to unreject it. I checked and we don't appear to rely on original_status being a particular value unless status_disabled_reason is also set to a none-None value so I can't (immediately) think of a problem with this.