Fix PTest for python-platformdirs

[0xba1a]

• Add new package python-iniconfig to SPECS-EXTENDED
• Update toolkit to include extended repos for build with check section enabled

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

• [x] The toolchain has been rebuilt successfully (or no changes were made to it)
• [x] The toolchain/worker package manifests are up-to-date
• [x] Any updated packages successfully build (or no packages were changed)
• [x] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
• [x] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
• [x] All package sources are available
• [x] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
• [x] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
• [x] All source files have up-to-date hashes in the *.signatures.json files
• [x] sudo make go-tidy-all and sudo make go-test-coverage pass
• [x] Documentation has been updated to match any changes to the build system
• [x] Ready to merge

---

Summary

Fix PTest for python-platformdirs

Change Log

• Add new package python-iniconfig to SPECS-EXTENDED
• Update toolkit to include extended repos for build with check section enabled

Does this affect the toolchain?

NO

Associated issues

Links to CVEs

Test Methodology

• Pipeline build id: local Buiddybuild will not work as it can't consider both SPECS and SPECS-EXTENDED at the same time and also the upstream extended repo is yet to be published.

[dmcilvaney]

Thoughts on making extended available to check builds, I've got two ideas:

1. This needs to be something done through the caching code, and very selectively. We are moving towards doing our package builds and checks in a single pass (see FastTrack) since it is much faster. This means that any change we make to the build has the possibility of affecting "real" package builds.

The way I could see us doing this is to have a second cache dir for testing only stuff, where we don't care as much. The fetcher would need to support that.

We would then need to add a new mount point, and a new repo source, for the builders.

2. When running a test, I believe the workers have network. We could add a fallback mechanism only for test nodes, where if we can't find a cached copy we try to use tdnf to get it during the build. This would add a lot of complexity to the graph/scheduler though, since those packages are indistinguishable from a normal unresolved remote node which would normally be considered a build failure.

[0xba1a]

Abandoning as it requires significant changes in toolkit which will be taken separately. Will take it once the planned toolkit refactoring is complete.