Not all network interruptions are resulting in prompt close listener calls or isActive state update

[leisurehound]

Describe the bug
Per the discussion, it appears that not all means of network interruption are resulting in a timely call to the close listener (and thus the isActive state update).

To Reproduce
Create a MQTTNIO.Client and successfully connect (I'm using HiveMQ in this instance)
Once successfully connected, leave WIFI on but disconnect from the current wifi access point (and have no other wired network connections)
The Xcode console will immediately report nw_proto_tcp_route_init [C1.1.1:2] no mtu received but it will take 45-90s for the close listener to be called.

Expected behavior
The close listener to be called as soon as NIO determines there is no longer a route.

Context (please complete the following information):

• Platform [e.g. iOS, macOS, Linux] macOS Ventura
• Swift/Xcode Version: 15.0.1
• Version 2.10.0

Additional context
I am also trying to run this on Raspbian Bookworm with swift 5.9.1 however I'm yet to determine a way to kill the Pi's wifi connectivity while retaining a session shell over ethernet to observe the behavior.

[adam-fowler]

I've had a closer look at this and the channel is not closed because it can be resurrected if the wifi connection is re-established.