Only disable sandbox while builing the builder, keep it enabled for actual builds

[gyscos]

This adds the --disable-sandbox flag to pacman commands, rather than disabling sandbox entirely.

The difference is that:

• It only applies if the DISABLE_SANDBOX build flag is passed (it is not passed in github's CI, where it's not needed)
• It has no effect beyond the initial "builder" docker image preparation. The pacman.conf patch leaked into the builder image and ended up applied un-necessarily for every runtime package build.

It's not a very critical thing - we already sandbox the builder in its own image so pacman's sandbox is of little benefits, but it's slightly cleaner not having to patch the pacman config.

[Lukas-Heiligenbrunner]

Thanks!
#205
In this PR i added the DisableSandbox to the pacman.conf since I was getting those landlock errors also on amd64.
(The builds were successful tho, only the warnings where annoying)

Are you sure this sandbox feature can work properly in a docker container (and maybe also second level inside an lxc/incus container)?

[gyscos]

I tested it on my machine so far. I believe truenas supports landlock by default, which is why pacman has been able to run fine in docker or lxc without disabling the sandbox. cat /sys/kernel/security/lsm does include landlock. The only missing part is really buildkit in docker-container driver mode (which is only required when building docker images for a different platform), which by default sandboxes the process and forbids the landlock syscalls (who will sandbox the sandboxer?...).

On github CI, I think it uses native workers to build the image, so no buildkit problem.

Still, I'll try to get a full arm64 build test on amd64 truenas to confirm that it works.

(This is overall a very low-priority PR, just an alternative solution to the landlock issue I had before you fixed in it #205)

I also wonder if cross-compilation using native compilers might be more performant than using qemu, but I guess not every package might work that way.

[Lukas-Heiligenbrunner]

I have to test this further when i have time.
cross-compilation using native compilers is definitly a thing we shouldn't consider since every package is built differently and the way the PKGBUILD defines how the package should be built isn't build to setup the cross toolchains correctly...
there would probably occur lots of build failures regarding this, we won't be able to fix.