ITS#2494 test016 failures

[hyc@highlandsun.com]

I've traced the problem, but I don't quite see what it should be doing
instead.

The ldapsearch requests are using the -S option to sort the results.
ldap_sort_entries calls ldap_count_entries to find how many items to sort.
That's fine, except that when ManageDSAiT is not used, the referral objects
are returned as search references, not as entries, so they are not accounted
for in this tally. The case that fails is

# base <c=US> with scope sub
# filter: (objectclass=*)
# requesting: 1.1

which yields 2 references and 3 entries, but 2 of the entries are at the end
of the response chain. ldap_sort_entries pulls the first 3 messages off the
chain and sorts them, even though two of them are not actual entries with
valid DNs. The head of the message is pulled off by ldap_get_dn() and then
passed to ldap_explode_dn() which returns NULL since the string is not a DN
(it's a URL). This list of 3 items (c=US plus 2 NULL values) is passed to
qsort and the result (comparing two objects with the same value) is
implementation-defined.

I guess we should classify this as a bug in ldap_sort_entries(). It's not
clear to me what a sensible behavior would be.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support