fix(user): enforce uniqueness on display names

[wescopeland]

SQL to Run Before Migration/Deployment:

-- reassign all display_name values to match User, which is already unique
UPDATE `UserAccounts`
SET `display_name` = `User`;

---

This PR adds a uniqueness constraint on UserAccounts.display_name. I don't believe it's desirable for two users to have the same display_name.

Also, the user profile route now supports navigation by display_name in addition to User.

[Jamiras]

From your migration SQL:

-- Set duplicate display names to NULL
UPDATE UserAccounts
SET display_name = NULL
WHERE display_name IN (

Wouldn't it be better to set display_name=User, which is already unique?

Probably doesn't really matter. The only users with display_names set are the ones that had non-ASCII characters: https://discord.com/channels/476211979464343552/1002697125081124986/1167420029113999370

[Jamiras]

I've also updated the SQL query in the OP to match your suggestion:

UPDATE `UserAccounts`
SET `display_name` = `User`;

Don't we still want to maintain those unicode values that already exist? (where not null, and resolve uniqueness)

[wescopeland]

If we do, I still think we should throw out the ones that I categorized as "crazy" earlier:

DELETE FROM UserAccounts
WHERE display_name NOT REGEXP '^[[:alpha:][:digit:][:space:]_.-]+$';

then:

UPDATE `UserAccounts`
SET `display_name` = 'User'
WHERE `display_name` IS NULL;

[Jamiras]

@luchaos - Since you went through the effort of transferring the non-ASCII usernames to the display_name field, what are your thoughts on sanitizing them?

There are currently six accounts that are incompatible with a unique key on display_name:

> select User, display_name, LastLogin from UserAccounts where display_name in (select display_name from UserAccounts where display_name is not null group by display_name having count(*) > 1) order by display_name;

Five of which haven't even been used as far as I can tell.

[wescopeland]

All display_name values in prod have been set to null: https://discord.com/channels/476211979464343552/718091467893243937/1272243405333856347

[wescopeland]

Going to go ahead and merge this to get it off our plate.

I'm not sure if we want to run this SQL query in any environment:

UPDATE `UserAccounts`
SET `display_name` = `User`;

MariaDB treats NULL as unique, and we currently don't have any code to write this value on new account creation (and I'm not sure that's desirable). My thinking right now is we continue to leave all display_name values as NULL until we support username changes.