[chore](build) Build BE against the prebuilt OpenBLAS and datasketches-cpp - #68619

…rty build

### What problem does this PR solve?

Issue Number: N/A

Related PR: apache#68619 (switches BE to these packages)

Problem Summary:

OpenBLAS (which faiss uses for the ANN index) and datasketches-cpp are git
submodules under contrib/. Every `build.sh --be` and `run-be-ut.sh` runs
`git submodule update` on them; on a fresh checkout that clones the whole
apache/doris-thirdparty repository for contrib/openblas (about 650 MB on
GitHub), or downloads a 24.7 MB tarball when the clone fails. Every cold BE
build then compiles OpenBLAS in its build directory: 6,725 build steps on macOS
arm64, where the rest of the BE is 740 unity steps, and 12,577 on Linux x86_64,
where DYNAMIC_ARCH builds kernels for every CPU generation. Doris does not
modify either library, so both belong in the third-party build like the other
dependencies. This PR adds them there. apache#68619 switches BE over and removes the
submodules; it can only land after the prebuilt third-party packages carry the
two libraries.

OpenBLAS 0.3.30 comes from the upstream release. The doris-thirdparty openblas
branch is that release plus two build-only edits (it forces
`-O3 -Wno-everything` so that the in-tree Debug and ASAN builds compile, and it
comments out a CMake message); every other file is identical, and a Release
third-party build compiles with -O3 anyway. It is configured the way
be/src/storage/index/ann/cmake-protect configured the in-tree build: static,
LAPACK built from its C translation plus ReLAPACK, no CBLAS, no Fortran, OpenMP
threading, no AVX-512. Three settings that the in-tree build took from the
machine running it are pinned, since a prebuilt archive is built on a CI runner
and then runs everywhere:

- NUM_THREADS=128. It defaults to the build host's core count and caps the
  threads one call can use at run time, so a 4-vCPU runner would cap it at 4.
- DYNAMIC_ARCH on Linux, now on aarch64 too, so the kernels are chosen on the
  CPU that runs BE. On aarch64 the in-tree build compiled for the build host
  only. The arm64 prebuilt is built on GitHub's Cobalt 100 (Neoverse N2)
  runners, and when OpenBLAS detects that core it compiles the whole library
  with -march=armv8.5-a+sve+sve2, which faults on Graviton2, Ampere Altra or
  Kunpeng 920.
- TARGET, the CPU the code outside the kernels is compiled for, which also
  follows the build host unless set (OpenBLAS's README recommends setting it
  with DYNAMIC_ARCH): HASWELL, or NEHALEM plus NO_AVX/NO_AVX2 when USE_AVX2=0
  as cmake-protect did, and ARMV8 on aarch64, the same baselines BE uses.

With gcc the build names the OpenMP flag and library itself. gcc in the LDB
toolchain v0.25, which the Linux job of build-thirdparty.yml builds with, is
configured for offloading (--enable-offload-targets=nvptx-none) but ships no
crtoffloadbegin.o or crtoffloadend.o, so every link with -fopenmp fails and so
does FindOpenMP's probe. Compiling with -fopenmp works, and a static library is
never linked.

macOS keeps host detection, as before. Homebrew's LLVM ships no OpenMP
runtime, so the build points FindOpenMP at Homebrew's libomp, the runtime BE
already links on macOS, and stops with an explicit message when it is not
installed. The macOS jobs of build-thirdparty.yml install it. The
apache/doris-thirdparty automation installs its own macOS packages and needs
the same addition before this lands, or its macOS legs fail at this package.

datasketches-cpp is pinned to 46025e9, the commit contrib/ pins, because no
release carries its HLL union fix yet. It is header-only and installs into
include/DataSketches, where BE included it from before apache#66511.

### Release note

None

### Check List (For Author)

- Test: Manual test
    - macOS arm64, clang 20: `build-thirdparty.sh openblas datasketches` with
      no libomp flags in the environment, as on CI. With a stubbed `brew` that
      has no libomp, the build stops with the explicit message.
    - Linux x86_64 in apache/doris:build-env-ldb-toolchain-latest:
      `DORIS_TOOLCHAIN=clang build-thirdparty.sh openblas datasketches`, the
      configuration of the doris-thirdparty automation; faiss built against
      the result passes the smoke test below. At run time DYNAMIC_ARCH picks
      the Nehalem kernels on the Rosetta-emulated CPU, and the library reports
      MAX_THREADS=128.
    - aarch64 DYNAMIC_ARCH with TARGET=ARMV8 and clang 20 (on the macOS host,
      as there is no aarch64 Linux image with the toolchain here): all 14 cores
      compile, the SVE and SME ones included, and on a CPU without SVE the
      library selects neoversen1 and passes the smoke test.
    - Smoke test: faiss linked against the prebuilt libopenblas.a runs
      IndexFlatL2 search (sgemm), PCA training (ssyrk + dsyev; the eigenvalues
      add up to the trace), OPQ training (sgesvd; the rotation is orthonormal
      to 1e-6) and IVF-PQ training and search under OpenMP, all correct.
    - Linux x86_64 in the same image with DORIS_TOOLCHAIN=gcc, the
      configuration of the Linux job of build-thirdparty.yml: without the
      explicit OpenMP settings configure fails with "Could NOT find OpenMP_C";
      with them both packages build. The gcc-built library calls the GOMP_*
      entry points; faiss built with clang against it passes the smoke test
      with the LDB libomp supplying them, so a third-party tree built with gcc
      still links into a clang-built BE.
    - The OpenBLAS 0.3.30 release differs from the doris-thirdparty openblas
      branch only in the edits described above (`diff -r`).
    - thirdparty/test: the download fallback, md5, juicefs mirror, azure retry
      and adbc JNI configuration tests pass.
- Behavior changed: No. Nothing uses the new packages yet.
- Does this need documentation: No

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>