UPnP: filter non-WAN device announcements before fetching description (#622) - #623

Summary

The SSDP discovery callback in CUPnPControlPoint::Callback handles UPNP_DISCOVERY_ADVERTISEMENT_ALIVE by downloading the device's description.xml first and only then checking the parsed deviceType for IGW (line 1234). On a typical home LAN — smart speakers, media renderers, mesh APs, ESP32 IoT devices all multicasting their own NOTIFY ALIVE announcements — amule fetches XML from endpoints it has no use for. Two consequences reported in #622:

• "Error retrieving device description" log lines fired at critical level for every device that returns a transient socket error or malformed URL. Stoatwblr's report shows both a SqueezeboxServer MediaRenderer and a Zyxel mesh WAP triggering it.
• libupnp's internal ThreadPool queue fills under announcement bursts (ThreadPoolAdd too many jobs: 100), because amule's callback is the slow consumer.

Fix

Filter UPNP_DISCOVERY_ADVERTISEMENT_ALIVE by NT (DeviceType in the UpnpDiscovery struct) before going near the network. The whitelist is the IGW family plus upnp:rootdevice (which is opaque from SSDP alone — the XML still has to be fetched to classify it):

• upnp:rootdevice
• urn:schemas-upnp-org:device:InternetGatewayDevice:*
• urn:schemas-upnp-org:device:WANDevice:*
• urn:schemas-upnp-org:device:WANConnectionDevice:*
• urn:schemas-upnp-org:device:LANDevice:*
• urn:schemas-upnp-org:service:Layer3Forwarding:*
• urn:schemas-upnp-org:service:WANCommonInterfaceConfig:*
• urn:schemas-upnp-org:service:WANIPConnection:*
• urn:schemas-upnp-org:service:WANPPPConnection:*

Prefix-matched (case-insensitive) so future :2/:3 UPnP revisions don't need code changes. The new helper UPnP::IsWANRelatedDeviceType lives next to the existing constants block.

case UPNP_DISCOVERY_ADVERTISEMENT_ALIVE: {
    /* fetch NT/DeviceType from the discovery struct */
    if (!UPnP::IsWANRelatedDeviceType(deviceType ? deviceType : "")) {
        break;
    }
    msg << "error(UPNP_DISCOVERY_ADVERTISEMENT_ALIVE): ";
    msg2<< "UPNP_DISCOVERY_ADVERTISEMENT_ALIVE: ";
    goto upnpDiscovery;
}

UPNP_DISCOVERY_SEARCH_RESULT processing is untouched — we explicitly issued an M-SEARCH for upnp:rootdevice and need to handle whatever the matching devices respond with.

Why not just demote the log

Two reasons we don't simply demote AddDebugLogLineC to AddDebugLogLineN:

1. Stoatwblr's primary ask is that amule "doesn't poke at anything which doesn't advertise as a WAN" — i.e. functional filtering, not just log suppression. Random LAN devices shouldn't see HTTP GETs from amule at all.
2. The libupnp ThreadPool too many jobs saturation is fixed only by returning from the callback faster, which requires not doing the download.

Validation

• macOS arm64, monolithic amule rebuilds clean.
• The empty-string and unrecognised-NT cases both return early without touching the network.
• IGW devices and ambiguous upnp:rootdevice announcements still fall through to the existing path so amule continues to detect and port-map against real routers.

Follow-up worth flagging

src/UPnPBase.cpp has ~30 #if UPNP_VERSION >= 10800 blocks carrying compatibility with libupnp 1.6.x. libupnp 1.8 shipped in April 2017 and every non-ESM distro has been on 1.8+ for years (Debian Buster shipped 1.8.4; Ubuntu 20.04+ on 1.14; Homebrew on 1.18). A separate cleanup PR collapsing those branches would simplify the file substantially — kept out of this PR to stay focused.

Closes #622.