ipam: keep the broadcast out of the occupancy bitmap
Ewah is a dense bitmap, one bit per index, so its size follows the largest
ordinal set in it. IPv4 reserves the broadcast, which is the LAST ordinal of the
pool, so creating a pool allocated a bitmap spanning the entire address range to
record two bits: 512 MB for a /0, which is what the 'pool create' and 'reserve'
fuzz cases have been timing out on.
The broadcast is not really an allocation, it is the ordinal above the
allocatable window, so model it that way: alloc_hi is the highest ordinal
request and reserve will hand out, and occ holds only the network address plus
what has actually been allocated. The bitmap then grows with use rather than
with the size of the address space.
mem still reports the broadcast as occupied and reserve still refuses it, now
as Already_allocated rather than by finding a bit; a reserved ordinal that
exists is taken, not out of range.