This was revealed when I made a cut-paste mistake in an upgrade to
virSocketAddrGetRange(), leading to failure to check for the end
address being outside of the defined network, but a negative test case
that should have caught the error instead returned success.

The problem was that testRange in sockettest.c was written so that
when it expected a failure, even an "unexpected success" would be
considered as an "expected failure" because of the way the check in
testRange was done. testRange had this:

 if (gotsize < 0 || gotsize != size) {
     return pass ? -1 : 0;
 } else {
     return pass ? 0 : -1;
 }

but all the tests that expected a failure give "-1" as the expected
size. So in a case where we expect a failure, we would have pass ==
false and size == -1. If virSocketAddrGetRange() was incorrectly
*successful* (returned some positive number), then "gotsize != size"
would be, e.g. "276 != -1", so we would take the if clause and, since
pass == false, we would return 0 (success i.e. expected failure).

The solution is that in the case where we expect failure, we should
just ignore size - virSocketAddrGetRange() must return -1 in order for
us to report "expected failure == success".

Part of fix for: https://bugzilla.redhat.com/show_bug.cgi?id=985653