Implement decision overrides in reviewer tools

[eviljeff]

Fixes mozilla/addons#16242

Description

When making a new decision, optionally allows selecting an existing decision to be overridden. When this happens the enforcement action for the existing decision is reversed first.

For complex cases where the decision to be overridden needs to be reversed first, there is an "Override Reverse-only" policy for the first override.

Context

Turned out to be quite a large pr! Properly overriding involved a lot of changes - really the PR is much more about ActionClass changes and not much in the reviewer tools code.

I had claude write the refactoring changes with overrides in abuse/actions.py, abuse/models.py, and the associated tests. I read all the changes, and they seem reasonable, but worth paying special attention nevertheless. I also followed up that refactoring with some manual clean-up.

Naming/terminology suggestions welcome for the new enforcement action and policy 🤷

Testing

Sync your Cinder policies + turn on waffle switch + enable the new Override Reverse-only for reviewer tools in django admin

Try:

• overriding a decision directly with a new decision (e.g. disable with approve) - should reverse and send an email
• overriding to Override Reverse-only policy - shouldn't send an email
• then overriding that override to a new decision (should sent an email)

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]

Example: previous decision disabled the add-on, and so all the versions; reviewer wants to override the disable with an an approve version, but those versions are not available for selection for the approve version.

I don't think that should be possible/allowed. If the add-on itself was disabled, we shouldn't allow an approve version, the force-disable should be reverted first separately.

[diox]

I don't think that should be possible/allowed. If the add-on itself was disabled, we shouldn't allow an approve version, the force-disable should be reverted first separately.

... Which seems to be the biggest issue here: how do we override a decision that resulted in the add-on being force-disabled, without an appeal ? I can't seem to do this with that patch, with or without selecting approve or approve add-on version policy.