When we search for duplicated stanza-ids we have to do it
in the context of an account

Use Gio.NetworkMonitor for reconnecting

See merge request gajim/gajim!149

Add symbolic icon

See merge request gajim/gajim!151

Fix #8749: Misleading error message when joining a room

Closes #8749

See merge request gajim/gajim!150

Distinguish between 'item-not-found' and 'remote-server-not-found'

Fixes #8749

- Some plugins do not depend on gui extension points and need the
roster to be initialized

- Add more logging

According to the XEP, caps hash has to be added to all presences

Plugins maybe want to use in their activation Gajim methods that
use an extension point. But because the PluginManager Object is not fully
initialized, the extension point method is not available yet

First create the PluginManager Object, then load Plugins.

- Plugins need the possibility to add caps before Gajim updates them

- This uses also NetworkManager, but also other more low level interfaces
on linux
- This should work cross-platform
- Leave network_watcher.py for now, because it shows how
to use the Gtk dbus interface

Regression introduced in 9b866fd1

Deduplicate based on stanza-id

See merge request gajim/gajim!148

- Add methods to determine the unique/stable id
- Write the id to the stanza_id DB field
- Add method to deduplicate based on the unique/stable id

- Calculating so many hashes for each Message is quite expensive
- It hides our own implementation bugs, like when we retrieve history
from a MUC with wrong timestamps, or on rejoin. We never know about it
because the Messages are dropped.
- It should not be necessary anymore. The original problem was a bug
in nbxmpp which triggered mass resending of old messages.

- Show new Symbol if a feature is available but not enabled
- Add this info to the tooltip

- add get_oob_data() so we can use it on more than one event
- also remove a forgotten print call

Add extension points to history window

See merge request gajim/gajim!147

Right now oob data is merged into the message text and stored into the DB.
If we load this message from the DB we cannot know anymore if and which
parts of the text was oob data.

Use the additional_data api to store oob data into the DB instead of
altering the original message text.

This lets us decide later on if and which data we want to display, even
on history replays. Also plugins can use the data.

Fix additional_data in events

See merge request gajim/gajim!146