Ordering of getipaddrs is inconsistent with system network interfaces

[omus]

Introduced in #30609 the output from getipaddrs is now sorted by IPAddr type and then IP address. Sorting this way ends up ignoring the network interface ordering of the system and may pick a less preferred interface.

For example on my system the current behaviour is:

julia> getipaddrs(IPv4)
2-element Array{IPv4,1}:
 ip"169.254.21.184"
 ip"192.168.1.63"

Where ip"192.168.1.63" is from my primary network interface "en0" and is my preferred address. The sorting also impacts getipaddr() which always returns the first address from getipaddrs:

julia> getipaddr()
ip"169.254.21.184"

The behaviour is different from previous versions of Julia and could cause issues when setting up a cluster.

We probably should avoid sorting the addresses from getipaddrs and at most only perform sorting of addresses that are from the same interface.

[StefanKarpinski]

So would doing a stable sort by type be adequate?

[omus]

I think so. The simplest solution would be to avoid the sort entirely.

[StefanKarpinski]

The idea behind the sort was that getipaddr used to be guaranteed to return an IPv4 address so we wanted to favor those in general. But getipaddrs is new, so we can return values in whatever order we want to. What about getipaddr though? Should it continue to return the first IPv4 address or the first address regardless of type?

[omus]

I would say that getipaddrs should return unsorted results and getipaddr could introduce a IPv4 bias internally.

[StefanKarpinski]

Triage is in favor. Would you mind making a PR, @omus?

[JeffBezanson]

Fixed by #32260