ipv6: Fix source address with many addresses in same network

[PetteriAimonen]

Summary

Previously ipv6 multi-address support decided packet source address based on its destination. This doesn't work if NuttX device has multiple addresses within same subnet. Replies will come from different address that the originator contacted, which causes warnings for ICMPv6 and stops TCP from working.

Instead when a packet is a response to existing connection, the source address should be based on the destination address used in the received packet.

RFC6724 does not go much into detail on this, but says:

Although source and destination address selection is most typically
done when initiating communication, a responder also must deal with
address selection. In many cases, this is trivially dealt with by an
application using the source address of a received packet as the
response destination and the destination address of the received
packet as the response source. Other cases, however, are handled
like an initiator, such as when the request is multicast and hence
source address selection must still occur when generating a response
or when the request includes a list of the initiator's addresses from
which to choose a destination. Finally, a third application scenario
is that of a listening application choosing on what local addresses
to listen. This third scenario is out of the scope of this document.

This commit implements it so that the destination address of received packet is used if it is among the local interface addresses.
If it is not, a best matching address is selected.

Related to #11054 and #11378.
@wengzhe Does this look reasonable to you?

Impact

Makes a difference only when CONFIG_NETDEV_MULTIPLE_IPv6 is enabled.
Affects ICMPv6 and TCP & UDP.

Testing

Tested with following addresses:

• NuttX eth0 assigned fd0f::e100 before ifup(), with netmask /64.
• NuttX eth0 added fd0f::1:0:e100 using ifconfig.
• Connecting from PC that has auto-assigned fd0f::aaa1:59ff:fe15:4b25 to itself.

[wengzhe]

Great, it seems reasonable to get a source address from the destination address when we're replying. I also found the same problem in ping6 just last week, and didn't get time to fully analyze this problem, thanks for checking it over protocols.