feat(environments): Make taxonomy reads + writes project–based

[Twixes]

Problem

#26521 added project_id to EventDefinition, PropertyDefinition, and EventProperty – along with some indexes based on project_id. However, these indexes are only useful if every row in these tables has project_id set, which is not the case. For GroupTypeMapping, we just did a backfill – that table had 5k rows per region, not a lot.
THESE tables have 100-500 MILLION rows per region and that's problematic. We can technically backfill, but that'd be a multi-hour migration, a significant challenge. (CC @PostHog/team-infra this is the long-running migration I was asking about in your channel)

Changes

Let's be smarter, if slightly messier, about project_id here. We don't actually need to backfill the field. The exact same behavior can be achieved by using coalesce(project_id, team_id) – so that's the expression we need to index on.

This PR drops the useless indexes on just project_id, and adds useful ones on coalesce(project_id, team_id).
We make those reworked immediately indexes useful in two ways:

• in rust/prop-defs, we're replacing ON CONFLICT (team_id, ...) clauses with ON CONFLICT (coalesce(project_id, team_id), ...)
• in Django, we're replacing filtering on team_id = %(team_id)s with filtering on coalesce(project_id, team_id) = %(project_id)s

How did you test this code?

Should pass existing Django tests.
Would be useful to add a test ensuring the ON CONFLICT logic works in prop-defs, but not sure if there's already a relevant test to edit, or where to add one. @oliverb123

[rafaeelaudibert]

Do we ever plan to drop team_id? If so, we're simply delaying the work :)

[Twixes]

@rafaeelaudibert Good question. I'm not planning that right now. This coalesce()-based filtering definitely is a kind of tech debt, but at the same time proper cleanup means a few migrations all-in-all affecting a billion+ Postgres rows, which we don't have a playbook for – I don't feel very comfortable running that, and it's a major time investment. I think this is a fairly sustainable shortcut as far as shortcuts go.

[oliverb123]

Hey! Best place to add tests would be in the tests/update.rs file. My recommendation is to use pure SQL expressions to set up a couple of test data rows in the way you expect, and then assert that the conflicts work etc.

[oliverb123]

Looks good, only note is that those queries you changed run a few thousand times a second at peak - when you merge this, you'll need to monitor RDS and be prepped to revert if it looks like the coalesce has added significant CPU cost to them (I don't think it will, just giving you a heads up). Once the deployments done, feel free to ping me so I can keep an eye on it too

[oliverb123]

Hah, thanks!