QWindowSystemInterface::handleShortcutEvent has a racy FIXME

This snippet is racy:

{
    // FIXME: Template handleWindowSystemEvent to support both sync and async delivery
    QScopedValueRollback<bool> syncRollback(QWindowSystemInterfacePrivate::synchronousWindowSystemEvents);
    QWindowSystemInterfacePrivate::synchronousWindowSystemEvents = true;

    if (QWindowSystemInterfacePrivate::handleWindowSystemEvent(shortcutOverrideEvent))
        return false;
}

This is the scenario:

• Input is being fed to Qt (via QWindowSystemInterface::handle* functions) from a separate thread.
• A key is being held (eg, "Alt") while some other input, like mouse movement, is also taking place.
• The pressed key is generating repeat events.

The snippet above gets called in the main/GUI thread. Between the time it sets synchronousWindowSystemEvents to true and the time it sets it back to false, the separate thread that is feeding input to Qt calls some QWindowSystemInterface::handleFooEvent function. The event generated from that call will be handled synchronously because synchronousWindowSystemEvents is true even though that QPA never called QWindowSystemInterface::setSynchronousWindowSystemEvents(true). This causes the input thread to sync with the GUI/main thread in QWindowSystemInterface::flushWindowSystemEvents(). The QPA implementation might be *relying" on it being async (because it set it to be so). This unexpected sync, which blocks the input thread making it wait on the GUI/main thread can cause unexpected problems, may even lead to a deadlock depending on the QPA implementation.