Better story for container image creation/management

Description

Currently the expectation is that CI jobs use containers that just "already exist", which typically means fairly minimal base images + installing dependencies every time, and maybe using hacky, non-optimal methods for caching dependencies.

Or, you can manage your own pre-cooked build containers, but then you're on the hook for lifecycling them, dealing with the various hassles of getting those to build on GitLab CI (dind or buildah if you have a privileged runner; Kaniko if you don't).

All of this is silly.

Proposal

GitLab CI should provide a first-class experience for managing its own CI container images.

• I should be able to point to a Dockerfile/Containerfile within my own repo, and have that be the build environment.
• I should be able to point to a Dockerfile/Containerfile specified by branch/tag/ref in another repo, similar to how include: works.
• For either of these options, I should be able to specify how often I want it fully rebuilt, whether it should be pushed anywhere, and if so, what the naming/tagging policy should be, and how many old tags to keep around.

My interest is specifically around the kubernetes runner, but in principle, this feature set should be possible to provide on any of the container-based setups.

Ticket requested by deastman on HN: https://news.ycombinator.com/item?id=28408351