✨ Add rule to resolve appeal on removed record

[foysalit]

No description provided.

[bnewbold]

I'm nervous about the volume of requests we'll need to make to ozone: a request on every post deletion would be a lot.

One way to reduce the volume would be to track appeals with a flag (using automod flagstore, based on redis), or a counter, and then do a check in the rule, and only update in those cases.

This would, of course, only work for new appeals, not any backlog of appeals.

I think we should basically always add mod actions for both accounts and records at the same time, so should have "resolve appeal" on account in addition to record in this PR, even if we only use the record version. I'm adding metadata population of appeal status to account metadata in a parallel PR, so we'll be able to check that at runtime if ever needed (eg, on account deletion).

[foysalit]

made a few changes following your recommendations and summarizing those below

1. we're using a counter to keep track of appeals on account/record (I think you added this as a flag on account meta in another PR) which is reset when resolve appeal event is emitted on the record/account.
2. on post delete, we're checking if the count is non-zero and emitting resolve appeal event on the record
3. on account event, if account is deactivated, we're checking if the count is non-zero and emitting resolve appeal event on the account

questions at this point

1. should we move away from the counter approach and use flags? I don't see any existing flagging mechanism on records
2. resolve appeal is usually followed by an ack event so we will need the ack event implementation from this PR :saprkles: Auto escalate accounts for high follow/like churn #740 to be merged in first (or I can just copy paste that over to here)
3. should we get the implementation out and leave it with a slack comment instead of actual resolve appeal implementation?

[bnewbold]

1. Flags might be workable, but I can't remember what the status of those are for records. Counter seems fine for this use-case! I should take another look at the "reset" code before giving a 👍
2. I pulled out and merged some of the escalate/acknowledge stuff, but not yet the record-level.
3. Yes, I would get most of the infra/implementation done separately before enabling the rule itself.

I merged a bunch of refactors recently, so probably need to do a rebase or merge of this branch.