RFC: Implement dbus-broker-session tool

[nolange]

This is a functional replacement for dbus-run-session, as this is often a very useful tool for testing / isolation (#145)

Exit codes and behavior is very similar,
the implementation is mostly shared with dbus-broker-launch, adding some hooks to start and supervise the application.

The target is to provide a minimal implementation, which can be enabled by creating a symlink named dbus-broker-session to dbus-broker-launch. Possibly this could be extended to also allow a symlink names dbus-run-session.
More complex functionality like supporting dbus-daemon or different dbus-broker-launch versions is not planned (like in #321), but could be done with simple shell scripts.

I believe this to be the best approach, and if merged it will quickly be available in distributions.

Please give me some feedback if this is worth pursuing (more than a version that "works-for-me"). I know it needs another pass in regards of code-style atleast, so general stuff would be needed to be sorted out first.

• prefer separate functions like help / help_session or common functions with flag like parse_argv
• posix_spawn or fork/exec
• error handling is ok? in regards to sd_event + the error_fold stuff
• I used getauxval because its used already in dbus-broker. but I would prefer getrandom.?
• socket path should try RUNTIME_DIRECTORY, XDG_RUNTIME_DIR first.

[nolange]

And I am not sure if launcher_connect
should connect to the "normal" user bus or the newly created one (which I currently do by setting DBUS_SESSION_BUS_ADDRESS early).
Might be better to use sd_bus_set_fd atleast if used via dbus-broker-session.

This is needed for authentication and further launching via systemd I suppose?
dbus-run-session can be called in an environment where the user dbus / socket is not available.
For example I am preparing a debian filesystem with an per-existing user, this needs calling dconf, gsettings and gio tools through dbus-run-session for the user before he is logged in for the first time.

Ideally dbus-broker-session could run without dbus-activation feature (I expect there to be problems launching via systemd anyway).

[dvdhrm]

Thanks for the proposal! Two comments:

1. Can you explain why you share the process with the launcher rather than as a separate executable? I have to admit I think the merged approach makes this less readable than a clear separation.

2. Any reason not to simply pursue session: implement dbus-broker-session #321 instead? I mean #321 works and it is fully compatible to dbus-run-session. If you rip out the clap dependency and parse the cli manually, it should be good to go.