Pin setuptools version to 70.3.0

[akkomar]

Recent releases of setuptools cause the build to fail. This fixes it and will unblock #822

Checklist for reviewer:

• Commits should reference a bug or github issue, if relevant (if a bug is referenced, the pull request should include the bug number in the title)
• If adding a new field, the field should have a description (see Bug 1652842 - Add a blocklist field so the environment schema works with pre- and post-bug-1647225 data #576 for an example)
• If coming from a fork, run integration tests: ./.github/push-to-trigger-integration <username>:<branchname>

For glean changes:

• Update templates/include/glean/CHANGELOG.md

For modifications to schemas in restricted namespaces (see CODEOWNERS):

• Follow the change control procedure

[sean-rose]

Does the newer setuptools cause problems running things locally? If so, then I'd think you'd also want to pin setuptools in requirements.txt.

[akkomar]

I'm not sure we should add setuptools to requirements: https://github.com/mozilla-services/mozilla-pipeline-schemas/blob/36abca46ba9a311628ef8cde510e9f74becba16a/requirements-dev.txt#L28C3-L29

[sean-rose]

Under normal circumstances I agree, but if the setuptools version incompatibility was going to consistently cause problems for devs that would take precedence IMO.

Luckily this is a moot point at the moment because it turns out the latest production versions of Python only come with setuptools 65 installed by default (and Python 3.8, which is the version used in the Dockerfile, comes with setuptools 56 by default).