network: custom DHCP range for isolated networks (API and UI)

[nagaboinaramgopal]

Description

An isolated guest network allocates guest IPs from the whole CIDR, so there is no way
to reserve part of the address space or keep the DHCP pool to a sub-range. createNetwork
already takes startip/endip, but NetworkServiceImpl only uses them for shared
networks.

This stores the start and end IP on an isolated network as a DHCP range, in two new
networks columns dhcp_start_ip/dhcp_end_ip, validated to be within the network CIDR,
in order, and not to include the gateway. NetworkModelImpl.getAvailableIps then restricts
the guest IP pool to that range when it is set; without one the whole CIDR is used, so
existing networks are unaffected.

The dnsmasq config on the VR is unchanged: for an isolated network it serves the host entry
CloudStack writes for the IP it allocated, so constraining the allocation is enough and no
system VM template change is needed. The range is returned by listNetworks as startip
and endip.

Creating an isolated network with a range needs gateway and netmask passed too
(already enforced by createNetwork), so the CIDR is deterministic. The create form shows
the start and end IP fields once a gateway is entered, and the network details tab shows the
range on an existing network, so the whole flow is usable from the UI.

Fixes: #12661

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• Build/CI
• Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Screenshots (if appropriate):

Isolated network detail showing the DHCP range, and the deployed VMs leased inside it.

How Has This Been Tested?

Unit tests in server, 101 green. NetworkModelImplTest adds two for getAvailableIps:
the pool is restricted to the range when set, and is the whole CIDR (minus the gateway)
when it is not. NetworkServiceImplTest adds five for the validation: a valid range is
stored, the end defaults to the start, and a range outside the CIDR, a start greater than
the end, or a range that includes the gateway are each rejected. DatabaseUpgradeCheckerTest
is green with the schema change. The two changed UI files pass eslint clean.

Manually on a KVM advanced zone. Created an isolated network with gateway 10.99.99.1,
netmask /24 and a DHCP range 10.99.99.10-10.99.99.20, confirmed listNetworks returned
that range, then deployed three VMs on it. All three leased inside the range
(10.99.99.14, .15, .19), where without the change they would draw from the whole /24.

How did you try to break this feature and the system with this change?

• Range outside the CIDR, reversed range, and a range covering the gateway are all rejected
  at create time.
• A network created without a range still allocates from the whole CIDR, so existing
  networks and shared networks are unchanged.
• Deployed several VMs against an 11-address range and confirmed each landed inside it.