API to acquire a connection fd from busd with pre-applied bus names & policies

[zeenix]

This is a clone of an issue filed by @poettering on dbus-broker (bus1/dbus-broker#259) 3 years ago. Copy&pasting verbatim:

I'd like to add support for a ".busname" concept in systemd, where people can declare a dbus service name to acquire as unit file, and it would list the full service name plus the matching policy. PID 1 would then parse that, and pass this to dbus-broker via some driver API, and get an fd back that can be used via socket activation.

The would fix a bunch of issues for us:

1. Solve the reordering mess when bus names are acquired that already have queued messages
2. Fixes issues with exit-on-idle: messages would remain enqueued on the bus connection while the service goes down, and it may continue where it left of — except if half-read messages remain
3. provide compatibility with the DynamicUser= concept of PID 1, as well as the "portable service" concept, as policy could be attached to the unit file itself

I'd suggest to drop the SASL and feature negotiation phase for sockets of this kind, i.e. sockets come readily set up for the main protocol of D-Bus. feature negotiation would have to take place in the unit files too, I guess.

Idea: dbus-broker's driver service would gain:

RegisterActivationService("sauaubas") → "has"

input:

 s → name to acquire
 au → list of uids that shall get access to this service
 au → list of gids that shall get access to this service
 b → boolean that decides if anyone else gets access
 as → feature flags requested ("unix-fd", …)

output:

  h → file handle of connection
  as → agreed on feature flags ("unix-fd", …), subset of same array of input

@poettering Can you please confirm this will be useful still, with a 👍 reaction?