[Task]: Make growth threshold before flagging relative instead of absolute

[diox]

Description

We currently flag add-ons that have their number of users grow above a certain rate threshold depending on their usage tier, but that threshold is an absolute number that is fixed for a given usage tier.

That approach doesn't play well with seasonality, we sometimes have higher or lower growth rates at specific times of the year for various reasons, and we don't want to constantly adjust the thresholds.

To address this, we should make that threshold relative to the mean growth (called hotness internally) for add-ons in the given usage tier instead of absolute.

Acceptance Criteria

Milestones/checkpoints

Beta Give feedback

1. Growth threshold before flagging is relative to the mean growth in the usage tier instead of absolute

Checks

• If I have identified that the work is specific to a repository, I have removed "repository:addons-server" or "repository:addons-frontend"

┆Issue is synchronized with this Jira Task

[diox]

Relevant code: https://github.com/mozilla/addons-server/blob/b9af959f76f9669de41fd4aca7c6d219557e5baf/src/olympia/addons/tasks.py#L528

For example, if an Addon has average_daily_users set to 50, it then belongs to the UsageTier that has lower_adu_threshold=0 and upper_adu_threshold=100. If the growth_threshold_before_flagging on that UsageTier is 5, then instead of flagging the add-on when their hotness value is 0.05 or above (hotness is a percentage), we'd flag it if it's 0.05 + {mean hotness value for all add-ons in that usage tier} or above.

Finding the add-ons should still be doable in a single query, though we probably need separate queries to determine the mean hotness for each usage tier.

[wagnerand]

Note on timing: To avoid running into the issues again that triggered this work item, this would need to be done for the last push this year, at the latest.