Replace RHEL 7 with CBL-Mariner

[BillyONeal]

Demonstration Build: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=9306853&view=results

We are being obligated to change our build environment for official releases to move away from RHEL 7.

• RHEL 7 goes out of support entirely in June
• RHEL 7 does not work with several of the centralized development tools to which '1 Engineering System' wants to be able to subject our official builds

This change replaces use of RHEL 7 with CBL-Mariner 2.0 ( https://github.com/microsoft/AzureLinux ), with a few dependent libraries from extremely old Ubuntu 16.04. This enables use of modern build tools and a modern host OS, consuming as little as possible from the ancient universe we must maintain to keep Linux binaries working for most of our customers.

This infrastructure is largely walking in the footsteps of the .NET team, see their write-ups https://github.com/dotnet/dotnet-buildtools-prereqs-docker and https://github.com/dotnet/runtime/blob/main/docs/workflow/building/coreclr/linux-instructions.md . However, we are not using their from-source clang implementation, instead using the gcc that comes with cbl-mariner.

The contents of the new Dockerfile are largely based on https://github.com/dotnet/arcade/blob/main/eng/common/cross/build-rootfs.sh , and the toolchain is largely based on https://github.com/dotnet/arcade/blob/main/eng/common/cross/toolchain.cmake .

I validated that the dependencies of vcpkg are the same before and after. From within the container:

root [ /build ]# curl -L -o before https://github.com/microsoft/vcpkg-tool/releases/download/2024-03-14/vcpkg-glibc
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100 7005k  100 7005k    0     0  8620k      0 --:--:-- --:--:-- --:--:-- 47.5M
root [ /build ]# ldd before
ldd: warning: you do not have execution permission for `./before'
        linux-vdso.so.1 (0x00007ffd9155b000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007faae0975000)
        libm.so.6 => /lib/libm.so.6 (0x00007faae088f000)
        libc.so.6 => /lib/libc.so.6 (0x00007faae068d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007faae097f000)
root [ /build ]# ldd vcpkg
        linux-vdso.so.1 (0x00007ffe62b71000)
        libm.so.6 => /lib/libm.so.6 (0x00007fe75e236000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007fe75e231000)
        libc.so.6 => /lib/libc.so.6 (0x00007fe75e02f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe75e996000)
root [ /build ]#

This also uses docker a bit better than before. Rather than minting a whole new container image containing the sources, now we just mount the sources in the right place.

This makes all infrastructure changes necessary to onboard 1ES Pipeline Templates.

[ras0219-msft]

This seems way excessive since we're SHA256-pinning the download above. Can we remove this and avoid checking in the .asc file?

[ras0219-msft]

[suggestion, not required]

When using apt, best practices are usually to:

1. Fetch new indexes
2. Install packages
3. Delete cached indexes

This is all done in a single RUN step to minimize the size of the produced image.

Is something similar we should be doing for tdnf?

[BillyONeal]

yum (and dnf (and tdnf)), to my understanding, does not have separate fetch indexes / install commands