[Task]: Show which restriction instance(s) caused content to enter a moderation queue

[wagnerand-moz]

Description

In order to understand why some add-ons enter the queue and assess the necessity for doing so, when the reason ultimately is a restriction, we'd like to see which restriction instance(s) caused this. We currently have two such restrictions, "Add-on Approval" and "Rating Flag for Moderation", so it would be great if we could it for both, but "Add-on Approval" is the more important one.

A list of restriction instances on the reviewer tools page linking to the instances on the admin could be an option, but open to others as well.

Acceptance Criteria

• A link between a submission and the reason (instance) it ended up in a moderation queue.
• Recorded in the database so it can be queried, e.g. using redash
• Exposed to humans for better understanding individual cases, e.g. on the reviewer tools page.

┆Issue is synchronized with this Jira Task

[diox]

Some notes:

• The starting point is if not RestrictionChecker(upload=upload).is_auto_approval_allowed(): in version creation code
• In RestrictionChecker._is_action_allowed(), we know which restriction class failed (we loop over RESTRICTION_CLASSES_CHOICES) but that's not enough. For each failed restriction class, if it is backed by the database, we should record which rows matched. That can be costly (it will bypass optimizations that we have to check all rows at once), and can return multiple rows, so it should only be done on failures.
• We already have UserRestrictionHistory + RESTRICTED activity log on the user but that only records the class, so some problem
• We also already have a DISABLE_AUTO_APPROVAL activity log for auto-approval but it doesn't record the restriction class at all, let alone link the specific row.