Add extension support to modules. This is a list of extension commands
that can be performed on the module.
Remove the custom registry of extensions and make proper modules that
implement the extensions.
This is more in line with what pulseaudio does. The advantage is that the
modules actually show up in the module list and that we can use the
module user_data to implement the extension later.
Make a new method to parse parts of the audioinfo based on custom
keys, leaving unparsed values to defaults. Implement the generic audio
parsing with this.
We can then remove some duplicate code where the audio keys didn't match
or where only parts of the info needed to be parsed.
Also make a method to serialize the audioinfo to properties and use that
when making arguments to load the modules.
Avoid doing some custom property serialization, move all key/values into
properties and serialize those with the generic functions.
We don't need to pass the client to the module create and load
functions, they can work without a client.
The only place the client is used is to access the properties to make a
new connection to pipewire. This is also however not a good idea, we
should simply use the defaults used by the context or else a client
could set strange properties like remote.name etc for these internal
connections.
Also removing the dependency of the client will make it possible to load
modules from the startup script or other modules later.
All modules need to manually create a `module` object and check
if it was successfully created. The same with argument parsing.
To simplify modules, move the module object creation and argument
parsing into `module_create()`, and pass the already initialized
module to `module_info::create()`.
The semantics of `module_info::create()` are kept, that is,
if it fails, `module_info::unload()` will not be called.
Move all module methods into the `module_info` struct, and place
all such structs into the "pw_mod_pulse_modules" section of
the executable. This way there is no need for an explicit
module registry, and all information about a module can
be declared in the module's source file in a single place.
While it is not a problem since `module_free()` calls
`pw_work_queue_cancel()`, it is completely unnecessary
to do it more than once.
Introduce a new flag on the module which stores whether or
not an unloading has been scheduled.
Create a new event for modules ('destroy') which is emitted from
`module_free()`. It is used by the module loading logic, to handle
when a module is destroyed without properly loading first.
Modules no longer need to emit the "loaded" event manually
if they can load immediately. In that case, the module loading
code will take care of emitting the event. If they can't,
they must return an async spa result, and emit the "loaded" event
when they see fit.
Fixes#1232
This starts breaking up the giant monolith that is the pulse-server.c
code into more manageable chunks by trying to split the module code into
individual compilation units.
