Bump setuptools to 69.0.*

[AlexWaygood]

Closes #11049
Closes #11066 (cc. @Avasam -- but I've listed you as a co-author, as I used your work for the second commit here :)

Here's the problem:

• At runtime, setuptools vendors packaging (as pkg_resources._vendor.packaging)
• We used to do that in the stubs too, to accurately reflect the situation at runtime. Now, though, setuptools's vendored version of packaging includes a py.typed file in that directory, which causes stubtest to get confused when comparing pkg_resources._vendor.packaging in the stub with pkg_resources._vendor.packaging at runtime (see the failing CI in [stubsabot] Bump setuptools to 69.0.* #11049)
• The obvious solution is to delete pkg_resources._vendor.packaging from the stub, and just declare that the stubs have a dependency on packaging. That doesn't pass our CI, however, because packaging isn't in the stub-uploader's allowlist -- and even if it were, it wouldn't pass our CI, because setuptools doesn't declare a dependency on packaging at runtime (it doesn't need to, since it vendors packaging). See the failing CI in Update setuptools to v69 #11066.

The "ridiculously dumb" solution is to continue vendoring packaging in the stubs, much as setuptools does at runtime. But instead of putting the vendored version of packaging in a pkg_resources._vendor.packaging directory (as it is at runtime), put it in a pkg_resources._vendored_packaging directory instead.

[Avasam]

I don't see a better solution. This is basically the same as when we create a shim for classes/methods we can't import. So we at least get the correct signatures.

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

[Avasam]

As mentioned in a previous comment:

I don't see a better solution [without introducing a change or special-casing in mypy/stubtest or stubuploader]. This is basically the same as when we create a shim for classes/methods we can't import. So we at least get the correct signatures.

Not the most straightforward PR to start with as a new maintainer :P But if you feel confident this doesn't need anyone else's review I'll go ahead and merge.

[AlexWaygood]

Not the most straightforward PR to start with as a new maintainer :P

Indeed not, but you're hardly new around here, eh ;)