Added citext migration to make username lookups case-insensitive (#2803)

[jestrada51]

Changes / Features implemented

Added a database migration that enables the PostgreSQL citext extension (if missing) and converts auth_user username field from varying to citext so username lookups within the API endpoints become case-insensitive.

Added a regression test (TestCaseInsensitiveUserQuery) that confirms /api/v1/profiles.json?users= correctly matches users regardless of casing (bob, Bob, bOb, etc.).

Steps taken to verify this change does what is intended

Manual verification of the migration was done to ensure that citext is included as an extension.
Manual verification of the API endpoints in curl was done in accordance to the example in the original #2803 post to ensure correct behavior
Test case was ran with different variants of the target username in order to make sure applying citext leads for case insensitivity.

Side effects of implementing this change

Api endpoints such as:

    /api/v1/profiles.json?users=<username>

and

 /api/v1/profiles/<username>/

are now case insensitive

A potential side effect is although citext was mentioned as a potential solution in the #2803 post, Changing the username column from varchar to citext may affect any raw SQL or third-party integrations that implicitly rely on the old column type.

Before submitting this PR for review, please make sure you have:

• Included tests
• Updated documentation

Closes #

[FrankApiyo]

Hey @jestrada51

Have a look at this: #2803 (comment)

[kelvin-muchiri]

@jestrada51 Kindly sign your commits. Refer to the contributing guide

[jestrada51]

Hey @FrankApiyo and @kelvin-muchiri.

I looked into collations over citext and have updated the migration to use the case-insensitive collation as recommended.
However, during migration, I encountered the following error:

django.db.utils.NotSupportedError: nondeterministic collations are not supported for operator class "varchar_pattern_ops"

After doing some research, I found out that this index ""auth_user_username_6821ab7c_like" is clashing with deterministic = false in the created collation which is needed to allow for case insensitivity in the username field.

I wanted to know if removing this specific index for the sake of having the collation run is a good idea and would not break anything important. I tried it on my local machine and it achieved case insensitivity for the mentioned api endpoints for #2803.

Let me know.

[kelvin-muchiri]

@jestrada51 Yes, the index will not be allowed on a field that has collation; go ahead and remove it