fix(settings): Unlock Settings mutex before emitting setting changed signals

When a setting is set it locks the Settings mutex and emits a signal for that
setting. If a slot is connected to that signal and lives on the same thread as
Settings, it is executed immediately with the Settings mutex still locked. That
slot can then lock a series of other mutexes. During this time another thread
can lock a mutex and then try to read settings, which will cause a deadlock due
to the opposite order of multiple mutex locking. By always emitting signals
after unlocking the Settings mutex, we avoid holding the Settings mutex while
executing slots.

Fix #6218

src/persistence/settings.h

@@ -230,7 +230,7 @@ signals:
     // Privacy
     void typingNotificationChanged(bool enabled);
     void dbSyncTypeChanged(Db::syncType type);
-    void blackListChanged(QStringList& blist);
+    void blackListChanged(QStringList const& blist);
 
 public:
     bool applyCommandLineOptions(const QCommandLineParser& parser);
@@ -572,6 +572,9 @@ private:
     friendProp& getOrInsertFriendPropRef(const ToxPk& id);
     ICoreSettings::ProxyType fixInvalidProxyType(ICoreSettings::ProxyType proxyType);
 
+    template <typename T>
+    bool setVal(T& savedVal, T newVal);
+
 public slots:
     void savePersonal(Profile* profile);