wxFileSystemWatcher: Transient directories may provoke a wxLogError

[dghart]

The tests run by e.g. the wx configure script create various dirs called conf*.dir, then quickly delete them again. If an app is watching the build dir with wxFileSystemWatcher, it receives the wxFSW_EVENT_CREATE and tries to add a watch for the new dir. There is then a race between the call to wxFileSystemWatcherBase::Add and the rmdir call. For me, that race is lost 2 or 3 times when I try to run configure. This doesn't in itself matter: there's no need to watch the dead dirs anyway. However wxFileSystemWatcherBase::Add (over)reacts by firing a wxLogError dialog for each failure.

I don't know what you'll feel the best response should be. Sending a wxFSW_EVENT_WARNING would be easy and informative, but slightly misleading as it's not actually coming from an inotify event. Perhaps just a wxLogDebug, or even a wxLogTrace; anything invisible to the user. I'll provide a patch once the decision has been made.

[vadz]

I think we might just return false from Add() without doing anything else. This is not ideal because it doesn't allow to distinguish between rare but expected errors such as this one (any file/directory could be deleted right at the moment when we decide to watch it) and catastrophic errors like failing to create the monitoring thread or something like this. But it's still better than an error dialog that can't possibly be avoided...

[dghart]

Thanks. The patch does include a harmless wxLogTrace, just for ease of future debugging, but I won't mind if you choose to omit it.

[VZ]

(In [73591]) Don't give error message for non-existent paths in wxFileSystemWatcher.

The file we're trying to watch might have been just deleted, this is an
unavoidable (and not only in theory but also in practice when watching busy
directories) race condition so don't give an error message if this does happen
but simply return false from Add().

Closes #15051.