[ZSvirt] bug: isIpv6RangeOverlap treats invalid ranges as overlapping

[tllovesxs]

Component

utils / network

Problem description

IPv6NetworkUtils.isIpv6RangeOverlap catches every exception from parsing/building the ranges and returns true.

Relevant code:
https://github.com/ZSvirt/zsvirt/blob/main/utils/src/main/java/org/zstack/utils/network/IPv6NetworkUtils.java#L202-L214

Malformed addresses and reversed ranges are therefore reported as overlapping. Callers use this predicate while validating or selecting networks, so invalid data can produce false conflict errors and mask the original input problem.

Steps to reproduce

Call IPv6NetworkUtils.isIpv6RangeOverlap with a malformed address or with a reversed range such as 2001:db8::10-2001:db8::2.

Expected behavior

Invalid input should not be reported as an overlap. The method should either reject invalid input consistently with the other validation helpers or return false after logging/validation.

Proposed fix

Validate the four addresses and return false for invalid/reversed ranges, or expose a throwing validation variant and keep the boolean predicate strict. Add regression tests for malformed and reversed ranges.

[tllovesxs]

I took another look at this and agree that the original return true is surprising for a method named isIpv6RangeOverlap. It also makes malformed or reversed input look like a real conflict.

At the same time, I did not want the fix to silently hide every possible runtime error. I pushed a follow-up commit to PR #37: invalid IPv6 input is logged and returns false, but only IllegalArgumentException is handled; unexpected exceptions are allowed to surface. This keeps the current predicate behavior for bad input while making programming or infrastructure failures visible.

The existing callers already validate the ranges before using this helper, so this is intended as a defensive boundary rather than a replacement for request validation.