feat: Add migration in advance of session properties PR

[robbie-c]

Problem

Pulled out of #21512 - doesn't affect anything else and makes the large PR easier to merge if we're not also doing a DB migration

select count(*) from posthog_propertydefinition

12,701,193

Changes

Support Duration properies (we already support these, but never server-side, they are just hard-coded client side).
Support session properties (also were previously client-side only)

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

Yes

How did you test this code?

Existing tests pass

[pauldambra]

without looking at the parent PR so not commenting on the why

we don't have a good way of testing/predicting what impact changes like this have on production 🙈

locally this runs and I can still filter properties afterwards

(to state the obvious - the alternative to avoid the DB migration is to have checks like this in the code (with the associated downsides of not having safety in the DB))

[pauldambra]

IIRC these are not really database changes so they have no effect on the DB

[pauldambra]

(i.e. Django lists them as migrations but they are no-op for postgres)

[pauldambra]

maybe this is the only written up previous incident from migrations

https://github.com/PostHog/incidents-analysis/blob/f27c0ea5a3d97dbe71ae44c2b31acf099537f481/2023-02-28-unsafe-migration-locks-up-postgres/incident.md?plain=1#L7

[pauldambra]

i think the drawback we have is even a canary deploy doesn't help us since it's the DB that we lock if something does go wrong

but I also don't think we have a good alternative here, this is what Django is going to do to make this change 🙈

probably we need to merge this when the system isn't under load and with someone from infra on hand ready to help fix all the things if it does cause downtime.

[pauldambra]

(and feel happily foolish if it goes in without incident :))

[robbie-c]

Django 4 supports AddConstraintNoValid which would be perfect here - you can add a constraint without checking that existing rows are valid, which is obviously correct when adding a new enum - sad we can't use that yet

[neilkakkar]

curious why you can't use it yet?

Also, I faced this before too, when we weren't on django 4.2, and I went this route to make it work -> https://github.com/PostHog/posthog/blob/master/posthog/migrations/0365_update_created_by_flag_constraint.py#L24-L27

[neilkakkar]

(and follow with a migration to validate the constraint) - could you check how big the property definition table is on prod?

[robbie-c]

@neilkakkar I'm being silly - I can use it. I've changed this PR to use it, and part 2 will do the validation

Part 2: #21777

could you check how big the property definition table is on prod?

select count(*) from posthog_propertydefinition
12,701,193

[neilkakkar]

Looks good to me! This extra effort with not valid constraints is indeed the way to go here - table + indexes is ~32GB so blocking can take more than a minute

SELECT pg_size_pretty(pg_total_relation_size('posthog_propertydefinition'));

[neilkakkar]

are types borked here?

[robbie-c]

Yeah, it does run locally though