Add method to update the client routes. Add an event when the client
routes changed.
Listen for route_changed events on clients that do a subscribe on the
stream-restore extension. Emit an EVENT when the routes change.
This keeps the system notifications volumes in sync between
gnome-control center and pavucontrol and probably in other tools
as well.
Fixes#3805
Add a function to check if a specfic custom log level has been defined
for a topic.
We can use this to dynamically check if we need to do the connection debug
messages.
We can also get rid of the conn.* pattern hack to disable connection
messages by default.
The default metadata update may be delayed for some time after
SET_DEFAULT, since the session manager has to work on it.
MOVE_* commands need to know what the client thinks is the current
default sink, so that they can decide between "move to default" and
"move to specific device".
To avoid race condition here, stash the default value set by the client
and use it in the MOVE_* commands, until the metadata update arrives.
Store a pointer to the owner `impl` object instead of
the (embedded) `stat` object. This way `message_free()`
can be simplified since the owner `impl` does not need
to be passed explicitly.
When the `disconnecting` flag was first added in
d44fdabea1, a client's
streams were not explicitly destroyed when it was freed,
instead, only the client's pw_core was disconnected,
which then caused all related streams to be destroyed.
Thus there needed to be a way to determine why the stream's
state changed to PW_STREAM_STATE_UNCONNECTED as it may have
been because the client is disconnecting or because the
stream has been "killed" in some other way.
The `COMMAND_{PLAYBACK,RECORD}_STREAM_KILLED` command
only needed to be sent to the client in the second case.
However, at the moment, all streams of a client are explicitly
destroyed before it's pw_core is disconnected. This makes the
`disconnecting` flag unnecessary, thus it can be removed.
Firstly, separate the message dropping logic into
its own `drop_from_out_queue()` function.
Secondly, do not check earlier messages if the NEW
event for a particular object has been reached while
processing a REMOVE event for that object.
Thirdly, if - while processing a REMOVE event -
the corresponding NEW event is found and dropped,
drop the REMOVE event as well.
See #1840
