[eglfs] Race condition between window system events and input events

Input events could potentially be sent to the wrong window when a modal dialog is triggered on eglfs, but not on XCB or Windows.

The problem can be QWindowSystemInterface::flushWindowSystemEvents() calls in the QPlatformWindow::setVisible() implementation of eglfs. If the flushWindowSystemEvents() is changed to flushWindowSystemEvents(QEventLoop::ExcludeUserInputEvents), then the behaviour is correct.

It can be, that without the QEventLoop::ExcludeUserInputEvents flag, it's effectively a race between showing the window and reacting to input events. This is especially obvious when we rapidly click/tap some UI component to cause a modal dialog to be created, some of those input events could be processed even before the modal dialog is shown. This could cause the modal dialog to show behind the window/widget that was clicked/tapped on with eglfs for example.

The attached demo shows a push button that creates a modal dialog when pushed, the dialog would show the number of nested exec()s being executed due to failure to block events going to the push button in time. If you click/tap the push button in rapid fashion, the "depth" value can get pretty big quickly.

It seems to be a bug to omit QEventLoop::ExcludeUserInputEvents from flushWindowSystemEvents().