compat: populate IPRange in IPAM config when listing networks

[crawfordxx]

Summary

When converting a libpod network to a Docker-compatible network in
convertLibpodNetworktoDockerNetwork, the IPAMConfig.IPRange field
was left empty with a // TODO add range comment.

This PR resolves the TODO by reconstructing the CIDR prefix from the
LeaseRange stored on each subnet. The forward conversion (Docker
IPRange CIDR → LeaseRange{StartIP, EndIP}) already exists in the
createNetwork path. This adds the reverse direction:

• Given StartIP and EndIP from LeaseRange, check whether they
  form a valid aligned IPv4 CIDR block (power-of-two size, aligned
  start address).
• If so, return the corresponding netip.Prefix as IPAMConfig.IPRange.
• Otherwise (non-CIDR-aligned ranges, IPv6) leave IPRange empty.

This means docker network inspect now shows the IPRange for
networks created with --ip-range (or the Docker compat API equivalent),
restoring round-trip fidelity for the IPAM configuration.

Fixes #28378

[crawfordxx]

The MacOS arm64 build failure appears to be a transient Cirrus CI issue — the change only touches pkg/api/handlers/compat/networks.go which has //go:build !remote && (linux || freebsd) at the top, so it is excluded from macOS compilation entirely. All Linux/cross-compilation builds passed.

[baude]

@crawfordxx i was able to rerun the test in question. it passed. Ive now asked for all failed jobs to retry. thanks for the PR

[baude]

ok, api test failures here now have been revealed.

[crawfordxx]

Fixed. The bug was in leaseRangeToIPRangePrefix: FirstIPInSubnet returns network+1 (first usable host), not the network address itself. So for 10.10.61.128/25 the stored StartIP is 10.10.61.129 and EndIP is 10.10.61.255. The old code computed count = 127, which is not a power of two, and returned false.

The fix recovers the network address as StartIP - 1, then computes size = EndIP - networkAddr + 1 = 128, which passes all checks and returns the correct 10.10.61.128/25 prefix.

[packit-as-a-service]

[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore.

[Honny1]

I have a few thoughts on this!

First, this function could be a lot shorter and cleaner. I'm not a huge fan of using raw bitwise operations here; we can make the logic much more elegant and readable. Here is a quick pseudocode mockup of what I mean:

FUNCTION leaseRangeToIPRangePrefix(leaseRange):

    // 1. Initial Validation
    IF leaseRange IS NULL:
        RETURN Null, False
        
    startIP = ParseIPv4(leaseRange.StartIP)
    endIP = ParseIPv4(leaseRange.EndIP)
    
    // Ensure IPs are valid and mathematically start <= end
    IF startIP IS INVALID OR endIP IS INVALID OR startIP > endIP:
        RETURN Null, False

    // 2. Calculate the total number of IPs in the range
    startInt = ConvertTo32BitInteger(startIP)
    endInt = ConvertTo32BitInteger(endIP)
    
    totalIPs = (endInt - startInt) + 1

    // 3. Verify the range size is a valid subnet size
    // A valid subnet size must be a perfect power of 2 (1, 2, 4, 8, 16, etc.)
    // In binary, a perfect power of 2 has exactly one "1" bit.
    IF CountSetBits(totalIPs) != 1:
        RETURN Null, False

    // 4. Calculate the subnet mask / prefix length
    // The number of trailing zeros in the total IPs equals the host bits
    numberOfHostBits = CountTrailingZeros(totalIPs)
    networkPrefixLength = 32 - numberOfHostBits
    
    proposedPrefix = CreateSubnetPrefix(startIP, networkPrefixLength)

    // 5. Verify network boundary alignment
    // The start IP must perfectly match the base network address of the subnet
    IF proposedPrefix DOES NOT EQUAL ApplyNetworkMask(proposedPrefix):
        RETURN Null, False

    // 6. Success
    RETURN proposedPrefix, True

Second, we definitely need to add unit tests for this function.

Lastly (and this isn't a blocker), something in the back of my mind is screaming that this function actually belongs in libnetwork under container-libs. WDYT? @Luap99