QLocalServer provides no way to know how to clean up if its listen() fails

QLocalServer has a fullServerName() that, after a successful listen(), reports the server name; on Unix, this is the path of an actual file that it's using.
However, if a process using a QLocalServer dies non-gracefully (e.g. tst_bench_qlocalsocket being killed by the QTest watchdog if it times out, see QTBUG-91713), it leaves that file lying around and subsequent attempts to run a process using the same local socket will fail to listen(). Having done so, they have empty fullServerName(), so the client process has no way to name the file in a "can you try to clear <filename> away ?" dialog, so the user has no way to know what to do about the problem. (I did not know where to look for the socket file when a test had timed out on a first run and thus could not get even the tests before that one to run after that failure until I found out where to look for the file. Ideally the test's cleanup() would be able to tidy away the socket on failure.)

So QLocalSocket::listen(const QString &) can leave the user stuck, unable to work out what to do about a program failing.
I can see three ways to solve this:

• qWarn() in the relevant code-path of the Unix backend's implementation that handles this failure mode;
• Ensure that the server's errorString() mentions the relevant file name on failure.
• Change the behaviour so that listen() doesn't clear d->fullServerName on failure, so that fullServerName() can report the name of the file listen() tried to use.

The last, although it's a behaviour change, has the virtue that the process that's blocked by such a failure can reasonably try to do something about the problem - either remove the file and retry or inform the user in a friendly dialog about the problem and what the user can do about it (and what to check before doing so, e.g. "if another version of me is running, you might want to join that instead"). The first only works for console apps, after all. The second does at least give the app a way to tell the user which file to kill.

If you opt to solve this by the behaviour change, please follow up by adapting the test to do something sensible about that file, when it's left lying around.