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",