mapping: fix bug when NotifyCallback is null

The change made in commit 41d8067 to
prevent a mapping's NotifyCallback from being called more than once
unnecessarily didn't correctly handle the case where the callback is
null. As a result, the callback would sometimes not be called at all in
situations where it should have been.
https://git.jami.net/savoirfairelinux/jami-client-ios/-/issues/410

Change-Id: Icce78210b8be873be244e93e430d8c6123619db9

src/upnp/protocol/mapping.cpp

@@ -299,6 +299,8 @@ Mapping::notify(sharedPtr_t mapping)
     NotifyCallback cb;
     {
         std::lock_guard lock(mapping->mutex_);
+        if (!mapping->notifyCb_)
+            return;
         if (mapping->state_ != mapping->lastNotifiedState_) {
             mapping->lastNotifiedState_ = mapping->state_;
             cb = mapping->notifyCb_;
@@ -320,6 +322,13 @@ Mapping::setNotifyCallback(NotifyCallback cb)
 {
     std::lock_guard lock(mutex_);
     notifyCb_ = std::move(cb);
+    if (!notifyCb_) {
+        // When a mapping is released by a controller, its NotifyCallback is set
+        // to null (see UPnPContext::releaseMapping). We need to reset
+        // lastNotifiedState_ when this happens to make sure the mapping isn't
+        // in a incorrect state if it's later reused by a different controller.
+        lastNotifiedState_ = std::nullopt;
+    }
 }
 
 void