ci: derived LLVM version too new #33345

Running the native MSAN job, it will install clang 21.1.1, which will result in a failure to clone the LLVM repo, as there is no 21.1.1 tag:

time env -i HOME="$HOME" PATH="$PATH" USER="$USER" bash -c 'MAKEJOBS="-j17" FILE_ENV="./ci/test/00_setup_env_native_msan.sh" ./ci/test_run_all.sh'
<snip>
+ [[ -n MemoryWithOrigins ]]
+ '[' -n 21 ']'
++ sed --silent 's@.*clang version \([0-9.]*\).*@\1@p'
++ clang --version
+ retry -- git clone --depth=1 https://github.com/llvm/llvm-project -b llvmorg-21.1.1 /llvm-project
Cloning into '/llvm-project'...
warning: Could not find remote branch llvmorg-21.1.1 to clone.
fatal: Remote branch llvmorg-21.1.1 not found in upstream origin
Before retry [#1](/bitcoin-bitcoin/1/): sleeping 0.3 seconds
Cloning into '/llvm-project'...
warning: Could not find remote branch llvmorg-21.1.1 to clone.
fatal: Remote branch llvmorg-21.1.1 not found in upstream origin
Before retry [#2](/bitcoin-bitcoin/2/): sleeping 0.6 seconds

cc @maflcko

In the apt.llvm.org packages clang --version includes the build commit hash, so we could do the following, although it is quite ugly:

     git init /llvm-project
     cd /llvm-project
     git remote add origin https://github.com/llvm/llvm-project.git
     LLVM_SHORT_HASH=$( clang --version | sed --silent 's@.*clang version [0-9.]* (++[0-9].*+\([0-9a-f]*\)-.*@\1@p')
     ${CI_RETRY_EXE} curl -s -H "Accept: application/vnd.github.v3+json" "https://api.github.com/repos/llvm/llvm-project/commits/${LLVM_SHORT_HASH}" -o llvm_commit.json
     LLVM_FULL_HASH=$(sed --silent "s@.*\"sha\": \"\(${LLVM_SHORT_HASH}[0-9a-f]*\)\".*@\1@p" llvm_commit.json)
     ${CI_RETRY_EXE} git fetch --depth=1 origin $LLVM_FULL_HASH
     cd /

https://github.com/davidgumberg/bitcoin/commit/d3f18db4ff49dd7b421c7b0f9e82f40a1463cc22

This appears to have been tagged 3 hours ago, so I think we can close this?

https://github.com/llvm/llvm-project/tags

+ retry -- git clone --depth=1 https://github.com/llvm/llvm-project -b llvmorg-21.1.1 /llvm-project
Cloning into '/llvm-project'...
Note: switching to '5a86dc996c26299de63effc927075dcbfb924167'.

Yea the tag now exists, but the potential for it to be broken is still the same for every new release.

Because they have an apt packaged version for a while before a GH tag?

Is there anything else we can do about that, other than make sure we only run the latest (GH) tag, rather then the most bleeding-edge apt package?

I think just using the a (recent) tag is fine, and avoids this issue entirely, rather than trying to match the libcxx build to whichever point release of Clang is being installed via apt.