There have been no breaking changes in the minor versions and there is
no ticket for unpinning this constraint. It doesn't make sense to keep.

It's only used by botocore and requests in the actual retirement code
and those have been able to handle a newer version of the library for
quite some time.

urllib3 is directly used in the testing code but not in a way where we
need to constrain it from being upgraded.

Previously we were doing the following query:

SELECT 1 AS "a" FROM "user_api_userpreference" WHERE ("user_api_userpreference"."key" = 'pref-lang' AND "user_api_userpreference"."user_id" = 1 AND NOT ("user_api_userpreference"."id" = 1)) LIMIT 1

Looking at the middleware, I don't see why this was previously
happening.

When linking a DRF serializer with a model, you need to link it to the
model class not an instance of the model.

The newer version of DRF tries to access the model_manager from the
model here and runs into issues if it's not defined correctly.

DRF was swallowing an underlying error string and providing its own
which was being checked for here.

See encode/django-rest-framework#8051 for
details.

The new version fixes that underlying issue and so the test failed.

Rather than checking for the exact string of the 404 which is not
relevant, we now just verify that the error code associated with the
request matches the HTTP response. This should make the test more
resilient to future text changes in the underlying Django function
`get_object_or_404`

The django.utils.timezone.utc is removed in Django 5.1.

issue: 37151

feanil/remove unnecessary pin

* fix: test failure in test_all_languages

replace assertQuerysetEqual with assertEqual dut to deprecation in Django 5.2