Do not use pip-install; add dependency cooldowns

[JelleZijlstra]

Zizmor recommends against pip-install (https://docs.zizmor.sh/audits/#misfeature).

Also add dependency cooldowns to prevent supply-chain compromises.

[github-actions]

diff-shades results comparing this PR (35461f0) to main (18684cc):

--preview style: no changes

--stable style: no changes

---

What is this? | Workflow run | diff-shades documentation

[cobaltt7]

Zizmor recommends against pip-install because it installs dependencies to the global scope and makes them vulnerable to dependency conflicts. This change does the same thing, just without being flagged by Zizmor. The correct fix to this would be to create a venv inside the workflow and install dependencies there. IMO that's overkill and unnecessary because there's only one pip-install per job and not much opportunity for conflicts

[cobaltt7]

setup-python 7.0.0 has removed the input: actions/setup-python#1336
Note again that this change is effectively the same as using pip-install, and installs into the runner-level environment. Again, I don't think this is an issue because we don't run multiple install commands or mix multiple tools. The proper fix to this would be to use a venv in each workflow, which to me feels like overkill, and IMO GHA should always have a quick-and-dirty way to install packages. It makes most sense to me to keep this until/unless it stops working

Would it be a bad idea to set PIP_UPLOADED_PRIOR_TO=P2D as a repository env value instead? That avoids repetition in workflow files and the possibility of forgetting to include it.

[JelleZijlstra]

A repository-level fix sounds good!

[cobaltt7]

virtualenv 20.39.1 (via hatch) uses pip 26.0: https://github.com/pypa/virtualenv/blob/20.39.1/src/virtualenv/seed/wheels/embed/__init__.py#L39

virtualenv 21.3.0 bumps pip to 26.1: https://github.com/pypa/virtualenv/blob/21.3.0/src/virtualenv/seed/wheels/embed/__init__.py#L42

Working around this by manually calculating PIP_UPLOADED_PRIOR_TO until we can bump virtualenv #5023 (blocked by #5037, which is blocked by pypa/hatch#2257)

[cobaltt7]

It's better to set PIP_UPLOADED_PRIOR_TO inline after all, because otherwise it won't be included in workflows triggered by forks. I also added it to the Dockerfile.