Remove transitive dependencies from "in" requirements files

[annamontare-nava]

JIRA Ticket:
n/a

What Does This PR Do?

Removes transitive and completely unused Python dependencies from "in" requirements files.

Transitive dependencies are those that are not directly used by our project's code, but are required by a dependency of our project's code (or that dependency's dependency, etc.).

Why?

• Some of these packages were completely unused: they were specified in the "in" files but not actually required by our code or any dependency of it. I assume they were once a transitive dependency, but are no longer. So by removing them from the "in" files, we can remove the package entirely. This reduces the size and attack space of our built images.
• For packages that are used, but only as a transitive dependency: specifying them in the "in" files has a few problems.
  • It is misleading to developers by making it unclear which packages our project directly uses.
  • If the authors of a package we depend on remove the package in question as a dependency, we will still include it in our images even though it may no longer be required.
  • If there are updates to the package in question, we don't get them when we re-generate our requirements files unless we manually update the version in the "in" files. This makes updating dependencies unnecessarily tedious.

In particular, this removes the following dependencies from our project:

removed from both requirements/requirements.txt and requirements/requirements.dev.txt:

['configparser',
 'django-localflavor',
 'importlib-metadata',
 'importlib-resources',
 'pkgutil-resolve-name',
 'py',
 'pybind11',
 'python-stdnum',
 'pyyaml',
 'zipp']

removed from requirements/requirements.dev.txt:

['django-debug-toolbar',
 'pycodestyle',
 'pyflakes',
 'setuptools-scm',
 'tomli']

What Should Reviewers Watch For?

If you're reviewing this PR, please check for these things in particular:

• Are any of the packages that were removed somehow needed for some reason?
• how can we socialize this with developers so we don't add back in transitive dependencies in the future?

Validation

Packages that were not actually used in our code directly were identified with deptry. For each package, I verified the import name (since it can be different than the package name)by skimming the package documentation, manually searched the repo using rg for any mentions of the import name or package name, and checked uv pip show to see what required that package. I also noted if the intro pages of the package's documentation mentioned any other ways of including the package besides Python imports.

Validation steps taken:

• built and ran locally
• testclient v2 and v3 auth flows and all resource calls using mock slsx
• account management: logging in, editing an app, adding a new app, deleting an app
• django admin
• removed and recreated local venv from scratch
• local unit tests
• local integration tests (2 failing, I think this is unrelated and pre-existing)

What Security Implications Does This PR Have?

Please indicate if this PR does any of the following:

• Adds any new software dependencies
• Modifies any security controls
• Adds new transmission or storage of data
• Any other changes that could possibly affect security?

• Yes, one or more of the above security implications apply. This PR must not be merged without the ISSO or team
  security engineer's approval.

Any Migrations?

• Yes, there are migrations
  • The migrations should be run PRIOR to the code being deployed
  • The migrations should be run AFTER the code is deployed
  • There is a more complicated migration plan (downtime,
    etc)
• No migrations