* Remove entirely the hook priority numbers and use before/after dependencies
* Split the WpEvent code out of WpEventDispatcher
* Add methods on WpEvent to interface with it from the WpEventDispatcher.
As a bonus, we can now also implement tooling to inspect which hooks would
in theory run for an event and write tests around that
* Removed some internal debugging facilities and log calls, will redo it later.
* Using spa_list now for the list of hooks, to reduce the number of allocations
happening in the "hook collection" algorithm
* Switched some internal data to use g_new0 instead of g_slice_new0
* Added g_free to free WpEvent structures... surprisingly, we were leaking them
before
It is better to have type-specific event names to minimize the amount
of constraint string matches we do on hooks, as most hooks (if not all)
are interested on specific types of objects only.
Similarly, use a different object manager for each object type to
minimize the performance impact of iterations and lookups, as all
such actions are interested in only 1 object type every time.
Port all existing hooks to the new event names and the get-object-manager API.
This avoids having to determine the subject type prior to pushing
an event from lua code and makes the call more convenient
Also add a debug statement to trace calls to push_event
* Use a common function to unwrap the objects out of the event
* Use the same common function to get the si flags
* Do not store back the si flags - there is no point in doing that,
tables are objects in lua and they are passed around by reference
* Store the target on the event
This can be used anywhere else in the codebase to push a "rescan-session"
event, making sure that there is only one such event pushed on the stack,
no matter how many times this is called.
Hooks need to have a priority relative to the event they are executed on,
so it does not make much sense to have all kinds of different priorities
based also on the event type and/or the module where they are defined.
Also, it wouldn't be acceptable to have such an enumeration on the public API.
After the creation of metadata with config data, m-settings will also need to
trigger the init of WpSettings Object/API. Earlier this was done in main.c as
part of init transition but the logic there is much more generalized now and so
it has been moved here.
- Support `priority` tag in definition of wireplumber components in json
config files.
- Support loading dangling components. These are components which are
NOT present in the json config files but present in the wireplumber
lookup folders.
- Simplify the init transition by removing the unneeded steps.
-Scripts loaded with wpexec will also need 'module-standard-event-source'
to be able to convert the pipewire signals to wireplumber events.
-Simplify the init transition states.
