[KYUUBI #7692][TESTS] Fix testFindLocalInetAddress on loopback-only hosts

[LuciferYang]

Why are the changes needed?

Closes #7692.

testFindLocalInetAddress branched on whether InetAddress.getLocalHost() was loopback and, in the loopback case, asserted that findLocalInetAddress() returns something else. The method has a third outcome the test did not account for: when the interface scan finds no address that is neither loopback nor link-local, it logs and returns the loopback address it started from. On such a host the assertion compares that address against itself and fails.

The test now branches on the outcome rather than on the starting address alone. When a replacement was scanned off an interface, it asserts the address belongs to an interface and is not link-local. Otherwise it asserts the original address came back unchanged, and when that address is loopback it also asserts no interface offered a usable one, which is what separates a correct fallback from a scan that silently returned loopback. The helper it calls only asks whether any interface address is neither loopback nor link-local; it does not repeat the selection rules.

Three decisions inside the method still have no assertion behind them, and are left for a follow-up: the host-name and IPv6 scope stripping, the IPv4 preference within the chosen interface, and the reversal that decides which interface wins when several have candidates. Only the first is writable against the current API, and on a host that picks an IPv4 address it asserts nothing; the other two need a seam that lets a test supply the interface list.

How was this patch tested?

build/mvn -o test -pl kyuubi-util -am -DwildcardSuites=none -Dtest=JavaUtilsTest
build/mvn -o spotless:check -pl kyuubi-util

That run does not reach the branch this fixes, because getLocalHost() resolves to a routable LAN address here. The fixed branch was exercised in a container that reproduces the failing host, where getLocalHost() and findLocalInetAddress() are both 127.0.0.1:

docker run --rm --network none --hostname loopbox --add-host loopbox:127.0.0.1 \
  -v ~/.m2:/root/.m2 -v $PWD:/src -w /src eclipse-temurin:17-jdk \
  build/mvn -o test -pl kyuubi-util -am -DwildcardSuites=none -Dtest=JavaUtilsTest

-o works with no network because the mounted ~/.m2 and the already-extracted build/apache-maven-* in the checkout are all it needs. Master's test fails there with expected: not equal but was: <loopbox/127.0.0.1>; this one passes.

Four mutations of findLocalInetAddress show the assertions are not vacuous. Each turns the test red, and the first three were reached by mapping the host name to 127.0.0.1 with -Djdk.net.hosts.file:

• dropping !addr.isLinkLocalAddress() from the candidate filter, so the method returns a link-local address: expected: <false> but was: <true>
• returning an address not bound to this host (8.8.8.8) instead of strippedAddress: expected: not <null>
• dropping the candidate filter entirely, so the scan returns 127.0.0.1 and the test takes the other arm: expected: <false> but was: <true>, from the assertion that there was nothing to find
• replacing if (address.isLoopbackAddress()) with if (true) so the scan always runs, no hosts file needed: the pass-through assertion fails because the scanned address differs from what getLocalHost() returned

Whether any of this runs on CI depends on how getLocalHost() resolves on a GitHub runner, which I did not check: a routable answer means the test takes the same assertEquals as master, a 127.0.1.1 answer means it takes the replacement arm. The fallback path is certainly not reached there, otherwise master would be failing today.

Was this patch assisted by generative AI tooling?

Assisted-by: Claude Opus 5

[LuciferYang]

cc @pan3793