Add slug field to Organization

[Twixes]

Changes

Slugs. We all love these slimy creatures, and today I'm honored to introduce them into our backend.

How so? Well, we want to point to organizations and projects with URLs instead of relying on User fields. We could just use IDs there… but they're completely not user-friendly. Obviously they are impenetrable for humans, but additionally:

• UUIDs are needlessly long for this use case
• autoincremented IDs are not professional, as they leak platform usage data

The solution that seems much better for humans is slug IDs. This PR adds them (inferring their values from entity display names) for orgs and projects, so that soon we can have URLs like this
app.posthog.com/orgs/hogflix/projects/foobar-test-123
instead of
app.posthog.com/orgs/12add3aa-5e5c-47dc-8bad-e39f83d45505/projects/666.

In the future slugs may also be fully customizable, but that's not important now, and the obstacle I encountered while trying that out is… our settings pages. They've been growing ad hoc with no layout system, and that just shows – it's getting awkward adding more options, as there's no structure to it all, and the number of Save buttons rises. I think it'll be worth thinking about a long-term system before adding more granular settings like this.

How did you test this code?

I ran the migration, including a case of duplicated names.
Also manually tried creating and renaming orgs/projects.
And there are some new tests including edge cases.

[Twixes]

This causes the backend checks to fail:

This is non-null very deliberately, by necessity, on relatively small tables – so I don't think we're in danger here. At the same time I don't know how to disable this check for migration operations that use SQL generated by Django (as opposed to RunSQL). Can it be worked around somehow, or does it have to be removed for this to pass? CC @timgl

[Twixes]

Actually I scaled this down to only add slug to Organization – I realized that the additional back-and-forth between the frontend and the backend to resolve project slug to project ID would be too impactful, while adding first-class project slug support to the API is not really feasible. It's definitely not ideal to expose serial project IDs, but I feel that for now it's a better option than slowing the app down.
Organization is less impactful for overall app performance and only relays on large UUIDs anyway, so slug is still the way forward there.

[paolodamico]

lgtm! I would only consider the migration question as potentially blocker

[paolodamico]

Maybe a better approach would be to generate a random 3 or 4 integer number and only try like 5 times?

[macobo]

We do something really similar in ee/clickhouse/materialized_columns/columns.py#materialized_column_name and I suggest that approach instead.

Basically if there's a conflict we generate a n-letter random ascii-letter suffix and append that. :)

Worth unifying the two approaches at least.

[Twixes]

Good idea, I unified the suffix logic using the materialized_column_name approach – more unique = better. Used the same in the migration.

[mariusandra]

If you change the organisation's name, and change its slug, all existing links/bookmarks for users will now be invalidated.

Do we want to

1. Keep this as is
2. Add logic to remember past slugs and redirect accordingly
3. Never change the slug
4. Add a large warning when editing the name

?

[Twixes]

I think this will be rare enough that we can put this off a bit, but in the end I think it'll be best for the slug to only be manually changeable in org settings. Maybe with a nicer settings layout, though that's not a prerequisite, just a very-nice-to-have. As for past slugs, would love some automagicness with redirecting from them, but at org level I'd prefer to free unused slugs up instead.