Support for RUN --mount=type=cache

[riconnon]

Description

I am investigating moving from docker build to buildah, but our existing build files make use of RUN --mount=type=cache to preserve things like package caches between builds and avoid continually redownloading the same artifacts.
This feature was stabilised in buildkit by dockerfile frontend version 1.2
Is this something that buildah is interested in supporting? If not, is there an alternative strategy to solve the same problem?

Steps to reproduce the issue:

1. Create a Dockerfile or Containerfile which does a lot of package (apk, pip, yarn, etc) installations
2. Run the build
3. Modify the build in a way that invalidates the main build cache for the RUN line, but does not modify which packages are downloaded

Describe the results you received:
The build downloads the required packages via the network each time

Describe the results you expected:
Ability to use RUN --mount=type=cache to permit the package files to be cached between builds

Output of rpm -q buildah or apt list buildah:

buildah-1.22.0-2.fc34.x86_64

Output of buildah version:

Version:         1.22.0
Go Version:      go1.16.6
Image Spec:      1.0.1-dev
Runtime Spec:    1.0.2-dev
CNI Spec:        0.4.0
libcni Version:  v0.8.1
image Version:   5.15.0
Git Commit:      
Built:           Thu Aug  5 20:03:31 2021
OS/Arch:         linux/amd64

Output of podman version if reporting a podman build issue:
N/A

Output of cat /etc/*release:
N/A

Output of uname -a:
N/A

Output of cat /etc/containers/storage.conf:
N/A

[rhatdan]

@nalind PTAL

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[flouthoc]

@riconnon for a workaround you could mount volumes from host and use it as a cache storage
e.g
buildah build -t test -v ~/hostdir:/containerdir:z .
there is a article showing a similar usecase https://www.redhat.com/sysadmin/speeding-container-buildah

I think this feature goes in parity with #3217 and can be easily implemented on top of it.So i think lets wait for #3217 first.

[flouthoc]

@riconnon Above patch should close this issue.