Docker build caching leading to security scan failures on streak2

[joshua-white]

Even when streak2 is fully patched, security scans find vulnerable packages inside persistent Docker BuildKit cache directories. These files are created while building GEOS base and TPL Docker images. They are not necessarily present in running containers, but they remain on disk after CI finishes and are therefore detected by host-level security scans. Manual pruning removes them temporarily, but subsequent image builds recreate the cache.

The fix proposed here continues building Docker/TPL images on streak2, but using a dedicated, ephemeral Buildx builder for each CI job. The existing workflow already creates such a builder, but the build script currently uses Docker’s persistent default builder instead. The proposed change would explicitly direct builds to the temporary builder and configure it to be removed when the job finishes.

This will likely not completely fix the issue as the core problem has to do with the security scans not recognizing backported security updates because it just naively checks version numbers. This fix here should at least get rid of our huge build cache files being saved and prevent future scans failing on very old caches.

[joshua-white]

Updated this PR to:

• Use per-job ephemeral Buildx builders with explicit cleanup.
• Remove locally loaded images after streak2 jobs.
• Avoid installing Sphinx—and its Jinja2/certifi dependencies—for ~docs builds.
• Preserve Sphinx for the Github-hosted +docs build.

This should prevent persistent cache growth and remove the known BCB findings from streak2 builds.

[victorapm]

If docker image rm fails for some reason, the CI job still succeeds and leaves the image behind. Should we make this a hard failure?

[victorapm]

Thank you, Josh!