gdbusauthmechanismsha1: Don’t delete a stale lock file if it’s changed

The retry loop for acquiring the lock for the authentication cookie file currently tries to acquire the lock for 0.5s, then gives up, assumes the lock file is stale, and deletes it.

That’s great if the lock file is stale because it’s been left there by a crashed process.

It’s not so great if the lock file just happens to have been there every time this process checked, because the cookie file is highly contested while (for example) running lots of parallel unit tests.

Check for that situation by comparing the mtime of the lock file and continuing to retry if it’s changed.

Signed-off-by: Philip Withnall pwithnall@endlessos.org

Fixes: #1929 (closed)

Closes #1929 (closed)