Merge #30283: upnp: fix build with miniupnpc 2.2.8

8acdf66 upnp: add compatibility for miniupnpc 2.2.8 (Cory Fields)

Pull request description:

  Fixes #30266

  Miniupnpc 2.2.8 [changed the function signature of `UPNP_GetValidIGD`](miniupnp/miniupnp@c0a50ce#diff-5a0d7cff00628c2c64a617edb347c0f283e3a75e7df910e7e8438fc6db23f610R122) without taking much care with the abi :(

  ~This is the minimal change to cope with that. Also included in this PR is a temporary bump to 2.2.8 to verify that it builds correctly. I'm happy to revert that and discuss the bump separately, as miniupnpc bumps require some scrutiny.~

  I believe that this is problematic if we build against one version and encounter a different one at runtime. This is not a problem for depends because we build statically. But for users who are self-building against shared system libs, care must be taken to run against the same version used for linking.

  Some quick digging shows that at least Ubuntu/Arch make the distinction between soversions:
  `libminiupnpc.so.17` -> `libminiupnpc.so.18`. So in practice, I suppose this shouldn't be much of a problem.

  Boooo for the upstream loose abi policy.

ACKs for top commit:
  edilmedeiros:
    reACK 8acdf66
  fanquake:
    ACK 8acdf66

Tree-SHA512: d2236ec8aef57a5c879065fbbe20080a14e4bf7b44c0bf506707eb946f72aa5837aba2fb2426d6853d21a9b77db5d72561d29d7ea645714d90309e11fe11d354

src/mapport.cpp

@@ -161,8 +161,11 @@ static bool ProcessUpnp()
     struct UPNPUrls urls;
     struct IGDdatas data;
     int r;
-
+#if MINIUPNPC_API_VERSION <= 17
     r = UPNP_GetValidIGD(devlist, &urls, &data, lanaddr, sizeof(lanaddr));
+#else
+    r = UPNP_GetValidIGD(devlist, &urls, &data, lanaddr, sizeof(lanaddr), nullptr, 0);
+#endif
     if (r == 1)
     {
         if (fDiscover) {