'RELENG_5_3_0_RELEASE'.

This commit was manufactured to restore the state of the 5.3-RELEASE image.

This is a corresponding change to bin/67994.  I'll soon commit
bin/67994 into 4-STABLE.  Actually, 5-CURRENT's getaddrinfo()
doesn't have the problem mentiond in bin/67994.  However, it is
good to be in sync variable name with 4-STABLE and KAME.

PR:		bin/67994
Submitted by:	JINMEI Tatuya <jinmei@ocean.jinmei.org>

Though it breaks RFC 3484, without this change, dest addr selection
doesn't work well under NAT environment.

Obtained from:	KAME

The getaddrinfo(3), getipnodebyname(3) and resolver(3) can coincide now
with what should be totally reentrant, and h_errno values will now
be preserved correctly, but this does not affect interfaces such as
gethostbyname(3) which are still mostly non-reentrant.

In all of these relevant functions, the thread-safety has been pushed
down as far as it seems possible right now.  This means that operations
that are selected via nsdispatch(3) (i.e. files, yp, dns) are protected
still under global locks that getaddrinfo(3) defines, but where possible
the locking is greatly reduced.  The most noticeable improvement is
that multiple DNS lookups can now be run at the same time, and this
shows major improvement in performance of DNS-lookup threaded programs,
and solves the "Mozilla tab serialization" problem.

No single-threaded applications need to be recompiled.  Multi-threaded
applications that reference "_res" to change resolver(3) options will
need to be recompiled, and ones which reference "h_errno" will also
if they desire the correct h_errno values.  If the applications already
understood that _res and h_errno were not thread-safe and had their own
locking, they will see no performance improvement but will not
actually break in any way.

Please note that when NSS modules are used, or when nsdispatch(3)
defaults to adding any lookups of its own to the individual libc
_nsdispatch() calls, those MUST be reentrant as well.

in KAME implementation, even when no policy is installed
into kernel, getaddrinfo(3) sorts addresses.  Since it
causes POLA violation, I modified to don't sort addresses
when no policy is installed into kernel,

Obtained from:	KAME

to RFC3493.  The previous change was related to RFC3484 (Default
Address Selection for IPv6), and it will come later.

(aka RFC2292bis).  Though I believe this commit doesn't break
backward compatibility againt existing binaries, it breaks
backward compatibility of API.
Now, the applications which use Advanced Sockets API such as
telnet, ping6, mld6query and traceroute6 use RFC3542 API.

Obtained from:	KAME

(aka RFC2553bis).  Now, getaddrinfo(3) returns EAI_NONAME
instead of EAI_NODATA.  Our getaddrinfo(3) nor getnameinfo(3)
didn't use EAI_ADDRFAMILY.

Obtained from:	KAME