[ZSvirt] bug: IPv6 security-group ranges are compared lexicographically

[tllovesxs]

Component

securityGroup

Problem description

IPv6 range validation compares the textual forms of the start and end addresses with String.compareTo instead of comparing parsed IPv6 values.

Relevant code:
https://github.com/ZSvirt/zsvirt/blob/main/plugin/securityGroup/src/main/java/org/zstack/network/securitygroup/SecurityGroupApiInterceptor.java#L809

For example, 2001:db8::2-2001:db8::10 is a valid ascending range numerically, but the string comparison sees "2" as greater than "1" and rejects it. Conversely, some reversed ranges can pass this check.

Steps to reproduce

1. Create an IPv6 security group.
2. Add a rule whose IPv6 source or destination range is 2001:db8::2-2001:db8::10.
3. Observe that the rule is rejected as an invalid range.

Expected behavior

IPv6 range ordering should be evaluated numerically after parsing both addresses.

Proposed fix

Reuse IPv6NetworkUtils.isValidIpRange or compare parsed IPv6Address values, and add regression cases for multi-digit host portions and reversed ranges.

[zsphere-opensource]

Could you add regression tests for this validation path?

Please cover at least:

• valid range: 2001:db8::2-2001:db8::10
• reversed range: 2001:db8::10-2001:db8::2
• invalid IPv6 endpoints
• compressed and expanded forms of the same IPv6 address

The fix changes the ordering semantics from lexical comparison to parsed IPv6 comparison, so these cases should verify both acceptance and rejection behavior.