These comments before aclIpNetworkCompare() turned out to be true:

These comments before aclIpNetworkCompare() turned out to be true:

  * NOTE: this is very similar to aclIpNetworkCompare and it's not yet
  * clear whether this OK. The problem could be with when a network
  * is a subset of the other networks:
  *
  * 128.1.2.0/255.255.255.128 == 128.1.2.0/255.255.255.0 ?
  *
  * Currently only the first address of the first network is used.

The aclIpNetworkCompare() function did not detect collisions and/or
overlapping addresses that can confuse the splay sorting algorithm.
This was proven with an ACL like:

acl a src 1.2.3.4/32
acl a src 1.2.3.0/24

...and then testing the access controls with this sequence of
source IP addresses:

9.9.9.9		correctly denied
1.2.3.4		correctly allowed
1.2.3.5		incorrectly denied
1.2.3.4		correctly allowed
1.2.3.3		correctly allowed
1.2.3.5		correctly allowed

This patch creates two functions for use by the splay library.  One
is used for inserting new ACL entries.  It complains when it detects
a collision/overlap.  The other is used for checking the access
control lists.

I also discovered that we were technically passing the wrong data
type to aclIpNetworkCompare() from aclMatchIp() (via the splay
routines).  The first argument was a 'struct in_addr' but should
really be a 'struct acl_ip_data'.  There was no harm, apparently,
because the first element of acl_ip_data is an in_addr, and the
only member that aclIpNetworkCompare() accesses.  Perhaps this was
intentional, but I doubt it.