We can now call wp_proxy_request_destroy() on endpoint links and
the WpImplEndpointLink together with the session item that created
it will be cleaned up
When a pw_global is removed on the server (by pw_registry_destroy() or other
means), it triggers the proxy removed & the registry global_remove callbacks,
but it does not necessarily destroy the pw_proxy.
For client proxies, we were previously destroying them by unrefing the WpProxy
in wp_global_rm_flags(), since the global was not "owned" by the WpProxy.
For impl proxies, we were not doing anything, as we expected that it would
only be removed from the registry if the local WpProxy was destroyed first.
This is not always the case, though, as the server or another client may
request to destroy this proxy with pw_registry_destroy()
Now we always destroy the pw_proxy as soon as it is removed from the registry,
no matter if it was a client or an impl proxy. If it was an impl proxy,
the WpProxy will continue to live and it's up to the code that created it
to handle the "pw-proxy-destroyed" signal and do something meaningful.
If it was a client proxy, the global will still unref the WpProxy right after
destroying the pw_proxy and there is no change in behavior.
Add the 'const' attribute to let the compiler know that it doesn't
need to call it multiple times for the same debug level argument,
since the enabled log levels cannot change at runtime.
The 'installed' signal can be used to know that there are no
known objects that are being prepared internally, so the object
manager is ready to use.
This also improves internal state management so that the 'objects-changed'
signal cannot be fired earlier than it should. Previously there
were corner cases with complex proxy features, as the object manager
relied on the fact that after a core 'sync' it is safe to assume
that all proxies are augmented... that's not always the case.
+ expose the export transition in the session item class
+ make the export-related flags immutable
+ add an export error flag
+ update and improve documentation
+ replace calling execute_step(..., STEP_ERROR) with rollback
+ implement deactivate internally using rollback
This unifies deactivation steps, which are common between deactivate()
and calling execute_step() with WP_TRANSITION_STEP_ERROR at the
end of a failed activation transition.
