fix(flags): Update feature flag insights when feature flag key changes

[haacked]

Problem

This fixes #24938. The original issue describes a problem when changing a feature flag key. In that situation, the system created insights aren't updated accordingly. In particular, the description and the query filter need to be updated to reference the new key.

Changes

This changes the feature_flag api update method to update the system generated insights for a feature flag. It changes the description to include the new key. It also changes the filter query value for the $feature_flag term.

However, it has a limitation in that it only updates those insights if the user hasn't changed the filter or the insight name. If the user makes a change to the insights, we don't want to inadvertently stomp their changes, so we ignore it.

Does this work well for both Cloud and self-hosted?

Yes

How did you test this code?

1. Wrote a couple unit tests.
2. Tested that renaming a key updates the description and filter for the insights.
3. Tested that renaming a key does not affect insights with a different name than the system generated ones.
4. Tested that if you update an insight, then update it back so it matches what the system generated insight looks like, then it will get updated again. This isn't a requirement, but just a side-effect of the implementation and is fine.
5. Tested that if an insight description matches system generated, but the filter does not, we do not update it. And vice versa.

[dmarticus]

this is generally excellent – thorough, clearly tested, and makes sense. I wanted to nitpick more but there isn't really a lot here that I think is worth nit-picking, to be honest. I left one note about my preference around raw f-strings vs helper functions but otherwise nothing blocking. I think I'll have more interesting feedback on a more complex PR ;)

[dmarticus]

this is a "dylan preference" thing (as compared to an encoded PostHog convention), but I generally don't think this pattern of writing helper functions that just return f-strings is better than using an f-string in the _create_tile_for_insight method – I feel like f-strings are more readable than this type of helper function. IMO, the reasons I'd change an f-string into a helper like this would be:

• we use this f-string a lot and copying the function saves a significant amount of characters
• the formatting is complex or has logical constraints around the values that it is formatting (e.g., something like this

def format_currency(amount, currency="USD"):
    if not isinstance(amount, (int, float)):
        raise ValueError("Amount must be a number")
    return f"{currency} {amount:,.2f}"

price = format_currency(1234.56)  # "USD 1,234.56"

would make sense as a helper function, since it does more than just format the currency.

In this case, though, I don't think there's value in writing helpers just to f-string a single use case.

[haacked]

Thanks for the feedback!

The reason I made these helpers is because they're used in two places:

1. _create_tile_for_insight
2. _update_tile_with_new_key

I didn't want to hard-code the same strings in both places just in case we ever update the descriptions for these tiles. I was concerned that someone changing the description when we create a tile, might not notice its usage in _update_tile_with_new_key, which could throw off the logic.