Update Earthfile to use uvx cmake

[eramongodb]

This PR replaces find-cmake-latest.sh with uvx cmake for Earthly tasks. To support uvx cmake, this PR also updates the Earthfile to migrate away from old/EOL/unsupported operating systems. A followup PR will migrate the rest of the EVG configuration to use uv to obtain preferred build tools as done in mongodb/mongo-cxx-driver#1428.

---

First, concerning the current Earthfile, the following operating system versions are removed due to being EOL:

• Alpine 3.16: EOL since May 2024.
• Alpine 3.17: EOL since Sep 2024.
• Alpine 3.18: EOL since Feb 2025.
• CentOS 7: EOL since June 2024.
• CentOS 8: EOL since May 2024. (Yes, it's before CentOS 7's EOL date. ¯\_ (ツ)_/¯)
• Ubuntu 16.04: EOL since Apr 2021 (ESM until Apr 2026).
• Ubuntu 18.04: EOL since May 2023 (ESM until Apr 2028).

Note

Although we do not have our own platform support policy document, both Evergreen and Server do not include "Extended Security Maintenance" mode in their range of support. Therefore, I do not think we should include them either.

These EOL versions are replaced with a full set of up-to-date and supported versions for their respective OS: up to Alpine Linux 3.22, Ubuntu 24.04, and CentOS Stream 10 (more on this below).

Second, to avoid the need to copy mongo-c-driver scripts into the Earthly environment, to better test OS compatibility, and to take advantage of Earthly containerization, the OS package managers are used to acquire uv instead of a uv-installer.sh script (which will be needed by EVG tasks). This led to some complications with using snap/systemd in containers, where snap is typically the OS-recommended alternative to obtain a missing or newer package than what is available via the system package manager. However, pipx is available as the second uv-recommended method to install uv (after curl | sh) on all relevant distros as a system package (when uv itself is not available via the system package manager), and so it is used instead when needed.

Third, Red Hat apparently ended support for CentOS in 2024 in favor of CentOS Stream (confusingly not the same thing as CentOS, but more or less its equivalent successor). Red Hat strongly recommends against continuing to use CentOS as it is "now exposed to significant risks". As part of this migration, official OCI images for CentOS Stream are now provided via quay.io rather than DockerHub. Therefore, the CentOS Stream images are specified using fully-qualified image names to quay.io instead of using $default_search_registry (at this time, the DevProd-provided Amazon ECR instance does not seem to support pull-through caching of quay.io images, only DockerHub images).

---

This PR also includes a drive-by addition of a -Wpoison-system-directories suppression with Apple Clang for the public-header-warnings target:

FAILED: src/CMakeFiles/public-header-warnings.dir/c-check.c.o
/usr/bin/clang -DBSON_STATIC -DMONGOC_STATIC -D_BSD_SOURCE -D_DARWIN_C_SOURCE -D_DEFAULT_SOURCE -D_MLIB_BUILD_CONFIG=Debug -D_XOPEN_SOURCE=700 -Icmake-build/src/libmongoc/src -Isrc/libmongoc/src -Isrc/common/src -Icmake-build/src -Icmake-build/src/common/src -Isrc/libbson/src -Icmake-build/src/libbson/src -m64 -march=x86-64 -Wno-unknown-pragmas -g -std=c99 -Weverything -Werror -Wno-declaration-after-statement -Wno-disabled-macro-expansion -Wno-c++98-compat-pedantic -Wno-pre-c11-compat -Wno-pre-c2x-compat -Wno-unsafe-buffer-usage -Wno-padded -Wno-reserved-identifier -Wno-documentation-unknown-command -Wno-unknown-warning-option -fPIC -MD -MT src/CMakeFiles/public-header-warnings.dir/c-check.c.o -MF src/CMakeFiles/public-header-warnings.dir/c-check.c.o.d -o src/CMakeFiles/public-header-warnings.dir/c-check.c.o -c src/c-check.c
error: include location '/usr/local/include' is unsafe for cross-compilation [-Werror,-Wpoison-system-directories]
1 error generated.

This warning is strange. I do not know why the changes in this PR (or the upcoming PR to apply uv to EVG scripts, I forget which) seem to trigger this warning. According to this comment, it may be related to the implicit use of the --sysroot flag on recent versions of macOS...? (There is no explicit --sysroot flag in the compilation command above.) We are definitely not attempting any cross-compilation in our macOS EVG tasks (that I am aware of), so I've opted to treat this as a false-positive and disabled it.

[kevinAlbs]

LGTM with one comment. The Earthfile maintenance and improvements are much appreciated.

[kevinAlbs]

Remove duplicate:

Suggested change

"u22",

[vector-of-bool]

Mostly LGTM, but pending comments regarding migrating away from CentOS.

[vector-of-bool]

Minor: Can this be modified to install uv elsewhere? e.g. set PIPX_BIN_DIR=/opt/uv/bin or use --global to install to /usr/local/.... I don't actually feel strongly about this, though.

[eramongodb]

Updated all pipx commands to install to /opt/uv/bin instead.

[vector-of-bool]

Following Red Hat's (wildly unpopular) decision to kill CentOS, Rocky Linux and AlmaLinux were created to take up the mantle as "drop-in-replacements" for RHEL. It may be better to switch to Rocky or Alma rather than use CentOS Steram as stand-ins RHEL 9+. Rocky and Alma are also available in docker.io, allowing us to continue to use ECR.

(RedHat killing CentOS is also the reason why CentOS 8 EOL is earlier then 7: They kicked the project to the curb at version 8 and didn't want to support it any more).

[vector-of-bool]

(This isn't a blocking request for changes, just an alternative to consider.)

[eramongodb]

I think we should keep CentOS Stream coverage for official Red Hat LTS compatibility coverage, but I'm fine with extending coverage to AlmaLinux as well, which cursory research suggests may have better community activity and support than Rocky Linux. Some additional context included below for reference.

Since AlmaLinux is meant to (almost) mirror CentOS Stream, a common CENTOS_STREAM_ENV is used to define both env.centos* and env.almalinux*.

---

Per Red Hat:

CentOS Stream will now be the sole repository for public RHEL-related source code releases.

Per AlmaLinux:

Red Hat announced they will no longer be providing the means for downstream clones to continue to be 1:1 binary copies of Red Hat Enterprise Linux (RHEL). [...] After much discussion, the AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead aim to be binary compatible with RHEL*.

* Binary/ABI compatibility in our case means working to ensure that applications built to run on RHEL (or RHEL clones) can run without issue on AlmaLinux. Adjusting to this expectation removes our need to ensure that everything we release is an exact copy of the source code that you would get with RHEL. This includes kernel compatibility and application compatibility.

The most remarkable potential impact of the change is that we will no longer be held to the line of “bug-for-bug compatibility” with Red Hat, and that means that we can now accept bug fixes outside of Red Hat’s release cycle. While that means some AlmaLinux OS users may encounter bugs that are not in Red Hat, we may also accept patches for bugs that have not yet been accepted upstream, or shipped downstream.

Per Rocky Linux:

Red Hat has recently expressed their perspective that they "do not find value in a RHEL rebuild." While we believe this view is narrow-minded, Red Hat has taken a strong stance and limited access to the sources for RHEL to only their paying customers.

Previously, we obtained the source code for Rocky Linux exclusively from the CentOS Git repository as they recommended. However, this repository no longer hosts all of the versions corresponding to RHEL. Consequently, we now have to gather the source code from multiple sources, including CentOS Stream, pristine upstream packages, and RHEL SRPMs. [...] we refuse to agree with them, which means we must obtain the SRPMs through channels that adhere to our principles and uphold our rights.

[vector-of-bool]

LGTM