[zigpy-review-bot]

Summary

Fixes #288. A stale next hop in the coordinator's routing table can keep MAC-ACKing frames without forwarding them, and Z-Stack then reports APS_NO_ACK rather than NWK_NO_ROUTE. Since #260, send_packet only rediscovers a route on NWK_NO_ROUTE (#273) and after MAC_TRANSACTION_EXPIRED, so the route is never repaired and downlink to the device stays dead until a restart.

Changes

• send_packet now treats APS_NO_ACK like NWK_NO_ROUTE for a unicast to a known device: it calls _discover_route and retries once. A second failure is raised as a DeliveryError as before.
• Broadcasts and multicasts (no device) are unaffected, and the existing MAC_TRANSACTION_EXPIRED association recovery is untouched.
• The route rediscovery test is parametrized over both statuses.

Open items

• A device that is genuinely unreachable (for example an asleep end device) now costs one extra route discovery and one extra send per send_packet call, on top of zigpy's own request retries.
• APS_NO_ACK can also mean the frame arrived and only the APS ack was lost, so the retry can repeat a non-idempotent command. This matches the behaviour before Zigpy application-level retries #260, when APS_NO_ACK was a routing error.

Testing

The full suite passes (397 tests) with zigpy 1.5.0. With zigpy 2.4.1 installed, the suite already fails on dev (138 failures, for example AF.DataRequestExt answered with CommandNotRecognized); that is unrelated to this change. Not tested on hardware.