* rani/inet_gethostbyname_fixes:
  inet_res_SUITE: testcase fixes for legacy DNS resolver (Solaris 8)
  inet_res: /etc/resolv.conf: use domain as default search list
  inet: delayed/avoided read of /etc/resolv.conf and /etc/hosts
  inet_gethost_native: workaround for empty result hostname on MacOS X
  inet_res_SUITE: testcase fix for empty domain name
  inet:gethostbyname improved to parse IP strings and look up own hostname

OTP-8426  The resolver routines failed to look up the own node name as
          hostname, if the OS native resolver was erroneously configured,
          bug reported by Yogish Baliga, now fixed.

          The resolver routines now tries to parse the hostname as an IP
          string as most OS resolvers do, unless the native resolver is
          used.

          The DNS resolver inet_res and file resolver inet_hosts now do not
          read OS configuration files until they are needed. Since the
          native resolver is default, in most cases they are never needed.

          The DNS resolver's automatic updating of OS configuration file
          data (/etc/resolv.conf) now uses the 'domain' keyword as default
          search domain if there is no 'search' keyword.

When the search list option in /etc/resolv.conf was empty, the
domain option was not used as default search domain.
That has been fixed in this patch.

Now inet:gethostbyname tries to parse the hostname as an IP string
first if the 'native' lookup method is not used. One can also
make the IP string parsing explicit using the new 'string'
lookup method, or avoid it using the new pseudo lookup
method 'nostring'.

In R13B04 a bug was introduced when the gethostbyname code
was rewritten, so if the native resolver was used and
misconfigured to not be able to look up the own hostname,
inet:gethostbyname also failed. This is now fixed.

* sc/sctp-connect-nowait:
  Implement a non-blocking SCTP connect

OTP-8414  There are new gen_sctp:connect_init/* functions that initiate an
          SCTP connection without blocking for the result. The result is
          delivered asynchronously as an sctp_assoc_change event. (Thanks
          to Simon Cornish.)

This patch adds a new set of functions - gen_sctp:connect_init/* that initiate
an SCTP connection without blocking for the result. The result is delivered
asynchronously as an sctp_assoc_change event.

The new functions have the same API as documented for gen_sctp:connect/* with
the following exceptions:

* Timeout is only used to supervise resolving Addr (the peer address)
* The possible return values are ok | {error, posix()}

The caller application is responsible for receiving the #sctp_assoc_change{}
event and correctly determining the connect it originated from (for example,
by examining the remote host and/or port). The application should have at
least {active, once} or use gen_sctp:recv to retrieve the connect result.

The implementation of gen_sctp:connect suffers from a number of
shortcomings which the user may avoid by using gen_sctp:connect_init and
adding code to receive the connect result.

First, irrespective of the Timeout value given to gen_sctp:connect, the OS
attempts and retries the SCTP INIT according to various kernel parameters. If
the Timeout value is shorter than the entire attempt then the application will
still receive an sctp_assoc_change event after the {error, timeout} is
returned from the initial call. This could be somewhat confusing (either to
the application or the designer!) especially if the status is
comm_up. Subsequent calls to connect before the OS has finished this process
return {error, ealready} which may also be counter-intuitive.

Second, there is a race-condition (documented in comments in inet_sctp.erl)
that can cause the wrong sctp_assoc_change record to be returned to an
application calling gen_sctp:connect. The race seriously affects connection
attempts when using one-to-many sockets.

Add first batch of tests for code:clash/0.

Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>