Work around SCTP quirks on sparc-sun-solaris2.10

This addresses the testcase failures mentioned in the parent commit,
which has been on account of the behaviour below, in which connect fails
on the loopback address. Work around it by finding/using another address
if possible.

$ erl
Erlang/OTP 20 [DEVELOPMENT] [erts-9.0] [smp:2:2] [ds:2:2:10] [async-threads:10] [hipe] [kernel-poll:false] [sharing-preserving]

Eshell V9.0  (abort with ^G)
1> {ok, LP} = gen_sctp:open().
{ok,#Port<0.439>}
2> gen_sctp:listen(LP, true).
ok
3> inet:socknames(LP).
{ok,[{{10,67,16,178},36506},{{127,0,0,1},36506}]}
4> {ok, S} = gen_sctp:open([{ip, {127,0,0,1}}]).
{ok,#Port<0.443>}
5> gen_sctp:connect_init(S, {127,0,0,1}, 36506, []).
{error,eaddrnotavail}
6> gen_sctp:connect_init(S, {10,67,16,178}, 36506, []).
{error,eaddrnotavail}
7> gen_sctp:close(S).
ok
8> f(S).
ok
9> {ok, S} = gen_sctp:open().
{ok,#Port<0.444>}
10> gen_sctp:connect_init(S, {127,0,0,1}, 36506, []).
ok

Even the following has been seen on at least one host, so that success
of gen_sctp:open/0 is no guarantee.

$ ifconfig -a4
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
bge0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1500 index 2
        inet 10.67.16.180 netmask ffffff00 broadcast 10.67.16.255
$ erl
Erlang/OTP 20 [DEVELOPMENT] [erts-9.0] [source] [smp:2:2] [ds:2:2:10] [async-threads:10] [hipe] [kernel-poll:false]

Eshell V9.0  (abort with ^G)
1> {ok, S} = gen_sctp:open(),
1> gen_sctp:connect(S, {127,0,0,1}, 3868, []).
{error,eafnosupport}
2> gen_sctp:connect(S, {10,67,16,180}, 3868, []).
{error,eafnosupport}

0 files changed, 0 insertions, 0 deletions