[chore](thirdparty) upgrade HADOOP_LIBS_3_4 to hadoop-3.4.2.4-for-doris

[morningman]

What problem does this PR solve?

Related PR: #66783, #66800

Problem Summary:

Picks up apache/doris-thirdparty#408, tagged as hadoop-3.4.2.4-for-doris. The single change over hadoop-3.4.2.3-for-doris is that macOS no longer builds libhdfspp.

That library does not link on macOS. It is compiled against Homebrew LLVM's libc++ headers, which are configured with _LIBCPP_HAS_VENDOR_AVAILABILITY_ANNOTATIONS 0, so std::exception_ptr's post-macOS-14 entry points are emitted whatever -mmacosx-version-min says, while -lc++ still resolves against the SDK's system libc++. Against a macOS 14 SDK that leaves __cxa_init_primary_exception and std::exception_ptr::__from_native_exception_pointer undefined, and the failing dylib takes the whole make down with it — libhdfs.a included:

Undefined symbols for architecture arm64:
  "std::exception_ptr::__from_native_exception_pointer(void*)", referenced from:
      std::__1::promise<hdfs::Status>::~promise() in filesystem_sync.cc.o
      ...
ld: symbol(s) not found for architecture arm64
make[2]: *** [native/target/usr/local/lib/libhdfspp.0.1.0.dylib] Error 1

Doris never links libhdfspp — be/CMakeLists.txt:251 sets BUILD_LIBHDFSPP OFF — so the fork now stops after the x-platform object libraries libhdfs pulls out of that tree. libhdfs.a, libhdfs.dylib, libhadoop.dylib, hdfs.h and the jars are all unchanged.

Linux is unaffected by the fork change, so this bump is a no-op there beyond the new tag. It is a prerequisite for #66800, which is where a macOS third-party build starts producing lib/hadoop_hdfs_3_4/ and therefore where the failure above shows up — on the macos-14 runner specifically. Note that master's build-thirdparty.sh still leaves hadoop_libs_3_4 out of the macOS package list, so the macOS legs of this PR's CI do not exercise the fork change yet; #66800 is what turns it on.

Release note

None

Check List (For Author)

• Test

  • Manual test (add detailed scripts or steps below)

  The fork was built end to end on macOS 26.5 / arm64 with the toolchain the macOS CI uses (Homebrew llvm@20, CMake 3.22.1, JDK 17, MACOSX_DEPLOYMENT_TARGET=12.0) before the tag was cut — hadoop-common-project 9/9, hadoop-hdfs-project 7/7, hadoop-dist all BUILD SUCCESS, producing

  lib/native/  libhadoop.dylib 159K   libhadoop.a 753K
               libhdfs.dylib   133K   libhdfs.a   1.4M    arm64
  include/     hdfs.h
  

  with no libhdfspp.dylib (8.9M previously), and libhdfs.a still exporting hdfsSetLogger, hdfsGetLastExceptionRootCause, hdfsBuilderSetKerb5Conf, hdfsBuilderSetKeyTabFile, hdfsUnbufferFile, hdfsFileGetReadStatistics, hdfsHSync and hdfsHFlush.

  The tarball this PR points at was downloaded twice; the MD5 is stable and the archive unpacks to doris-thirdparty-hadoop-3.4.2.4-for-doris/ as HADOOP_LIBS_3_4_SOURCE expects.

• Behavior changed:

  • No. Linux builds byte for byte the same library set; macOS drops a library nothing links.

• Does this need documentation?

  • No.

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[morningman]

skip buildall

[github-actions]

PR approved by at least one committer and no changes requested.

[github-actions]

PR approved by anyone and no changes requested.