Include interface ID in the PeerAddress that gets handed up from UDP/TCP code

[bzbarsky-apple]

Problem

When our UDP and TCP code hands a PeerAddress up the stack for incoming messages, it does not include the interface id in that PeerAddress. When upper layers then update their cached PeerAddress based on the incoming address, they can lose the ability to send messages properly (e.g if sending to an IPv6 link-local address).

Change overview

Hand up the right interface ID if we can. For TCP this is half-baked at best and definitely does not work for LwIP.

Testing

Manually tried running /out/debug/standalone/chip-tool onoff toggle 1 when paired to a device that has an IPv6 link-local address. Without these changes the message gets sent but the standalone ack for the response gets "No route to host". With these changes, the ack is also sent correctly.

[todo]

Does netif_get_by_index(mTCP->netif_idx) do the right thing? I

connectedhomeip/src/inet/TCPEndPoint.cpp

Lines 705 to 715 in 9d9cce1

	// TODO: Does netif_get_by_index(mTCP->netif_idx) do the right thing? I
	// can't quite tell whether LwIP supports a specific interface id for TCP at
	// all. For now just claim no particular interface id.
	*retInterface = INET_NULL_INTERFACEID;
	return INET_NO_ERROR;
	#endif // CHIP_SYSTEM_CONFIG_USE_LWIP
	#if CHIP_SYSTEM_CONFIG_USE_SOCKETS
	union
	{
	sockaddr any;

---

This comment was generated by todo based on a TODO comment in 9d9cce1 in #7389. cc @bzbarsky-apple.

[todo]

Is there still a meaningful interface id in this case?

connectedhomeip/src/inet/TCPEndPoint.cpp

Lines 738 to 748 in 9d9cce1

	// TODO: Is there still a meaningful interface id in this case?
	*retInterface = INET_NULL_INTERFACEID;
	}
	return INET_NO_ERROR;
	}
	#if INET_CONFIG_ENABLE_IPV4
	if (sa.any.sa_family == AF_INET)
	{
	// No interface id available for IPv4 sockets.
	*retInterface = INET_NULL_INTERFACEID;

---

This comment was generated by todo based on a TODO comment in 9d9cce1 in #7389. cc @bzbarsky-apple.

[woody-apple]

@msandstedt @andy31415 @jepenven-silabs ? Would love some eyes on this to unblock testing. Thanks!

[woody-apple]

@saurabhst ?

[msandstedt]

As far as I know, sin6_scope_id will only be an interface ID for link local addresses. So in short, no, I don't believe an interface ID can be extracted for addresses other than link-local. And I can't think of a reason why we would need this for non-link-local addresses. In theory we could bind to a specific interface at which we know a device may reach us. But I don't know why we would want to or need to.

As to the other possible overloaded meanings of sin6_scope_id (zones or site indices?), it's hard to imagine these would be useful to us, or could even be dealt with in a portable way. I don't know much about those though, except that they are not interface indices.

TLDR: It looks to me like the code is doing the correct thing here.

[bzbarsky-apple]

Thank you for looking into this! This part I was really not sure about, as you can tell from the comments. ;)