Replace last_content_review_pass with content_review_status

[eviljeff]

Fixes: mozilla/addons#16049; precursor to mozilla/addons#15989

Description

last_content_review_pass didn't store enough information, so it's replaced with an int with EnumChoices. Also addresses a deficiency with mozilla/addons#15988 - after a content review rejection the add-on was still in the queue.

Context

Mainly test changes and migration code 🤷

Technically I didn't need to differentiate a content review, and a content review triggered after a previous pass, but it seemed like data we might want at some point.

CONTENT_REVIEW_STATUSES.UNREVIEWED is really None rather than 0 but because of reasons None is annoying to have as as valid state (e.g. you can't have it in a Subset), so we need a 0 state. content_review_status will be null=False in a subsequent deploy.

AddonApprovalCounter.CONTENT_REVIEW_STATUSES is quite wordy.... It could be improved with mozilla/addons#16015 ... so would it be more disruptive to do this at the same time, or less? In the end I left it alone - this pr has a functional changes; whereas mozilla/addons#16015 should be functionally identical, with just code refactoring.

Testing

Some of this is impossible to real-test at this point, without the ability to request a new review directly, but you can test some parts, and tinker with the states otherwise:

• identify an un-conteent reviewed unreviewed add-on in the reviewer tools (either a fresh one, or delete it's AddonApprovalsCounter instance) and see it's in the queue. (Make note of it's original status)
• Content reject it.
• The add-on should no longer be in the content review queue, and should be marked as Rejected in developer hub
• use django shell to change the state of it's AddonApprovalsSummary.content_review_status to REQUESTED (4)
• See the add-on is back in the content review queue
• approve it this time
• add-on should be back to it's original status.

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]

how is that line passing linting checks...

[eviljeff]

that's weird - ruff doesn't correct these kind of long times, but I expect make lint to pick it up at least.