Use the default fallback path for the session bus

[WhyNotHugo]

This is currently a de-facto standard done by most libraries, and is being amended into the spec itself1.

The previous behaviour (starting a new D-Bus server via dbus-launch) is generally discouraged, since it will start a D-Bus at a non-standard location and other processes have no mechanism via which they can locate the bus socket.

Fixes: #372

[guelfey]

I'm a bit on the fence here - I can see that dbus-launch is usually not helpful, but generally I find it useful to stick to the official spec - after all, ensuring that different implementations have the same rough behavior is what the spec is for. So I'd say this can be merged as soon as it's adjusted in the spec itself (the MR you linked is not merged yet).

[WhyNotHugo]

I'm a bit on the fence here - I can see that dbus-launch is usually not helpful,

This issue bit me again and I have to say; this isn't merely unhelpful, it hides the real issue when something is wrong.

When the environment variable is missing, the client code starts its own server. Starting a new server leads to ridiculous issues while debugging, because one tries to figure out why messages from one peer aren't properly received by another, only to eventually find out that one peer started its own server instance and is talking to that.

Even returning an error would be better (and make a lot of sense, since we're telling the client to connect to a server but the variable specifying which server is unset).

but generally I find it useful to stick to the official spec - after all, ensuring that different implementations have the same rough behavior is what the spec is for.

The MR for the spec update is still un-merged, but I can't find any other client implementation which doesn't follow this behaviour. It's pretty much the de-facto standard.