Upgrade requirements

[millerdev]

First part of https://dimagi-dev.atlassian.net/browse/SAAS-11205

SUMMARY

Pin several unsafe library upgrades and a security update, and then upgrade requirements using make upgrade-requirements.

RISK ASSESSMENT / QA PLAN

The risk of this change set is hard to evaluate since many things are changing. However, the change log of every library that is being upgraded has been assessed to ensure as well as possible that no major/breaking changes are included in these upgrades.

Notes on pinned libraries

• django-phonenumber-field - big jump, possible issues:
  • 2.4.0: Saving or filtering by an invalid phone number will now raise a ValueError.
• django-redis - wants to downgrade to 4.9 (was 4.10)

Took a slight risk on these

• jinja2 - many changes in 2.11.0, not sure about backward compatibility
• python-dateutil
  • 2.8.1 made several changes that seem possibly not backward compatible
    (although probably unlikely to cause issues)
    • parser.parse will now raise TypeError when tzinfos is passed a type that cannot be interpreted as a time zone. Prior to this change, it would raise an UnboundLocalError instead. UnboundLocalError does not appear anywhere in our codebase.

I toyed with the idea of rolling out upgrades in smaller chunks, but the dependency graph is complex enough that it felt simpler to try them all in one go to see if tests pass. Test failures should hopefully provide an easy non-arbitrary way to find problems. The final commit of this PR could still be split into multiple chunks if there are no test failures but the risk still seems too large to roll out all at once.

Review by commit.

[dannyroberts]

Huh interesting. What does this do?

[millerdev]

It removes /vendor/bin/pip from bash's command cache. This is necessary if the command path changes, as is the case when pip is upgraded on the line above.

[millerdev]

QA Pass. Waiting to merge until after the weekend.