If the SettingsUpdated event for whatever reason got slightly delayed and arrived AFTER
the save request was already processed, in rare situations it could happen that the
"Settings Changed" popup was triggered even though the settings had already been
successfully saved.
Modified such that we now keep track of if we already saw the SettingsUpdated event
associated with our save request and if not we ignore the next one.
To ensure that we don't get out of sync due to that when a settings update request is
sent, but no settings are actually change, we also now always trigger the SettingsUpdated
event, even in such cases. Clients can use the hashs in the payload to test if something
actually changed - if necessary.
5b910b557e