Thanks Michael Biebl for pointing out!

https://bugs.debian.org/1078801

These tests assume "No log entries" for test.service initially. This
isn't true when running `testLogs{,User}` or `testBasic{,User}` more
than once on the same machine. After an hour of effort trying various
tricks with overlaying /{run,var}/log/journal and restarting journald it
turns out that there just simply isn't any reliable way of resetting the
journal. So give in, and make these four tests destructive.

This was introduced in commit 66ff88e mostly for cockpit-machines.
Since then most of these hacks disappeared, but there's two left.

`StorageControl` avoids that problem by wrapping the `Tooltip` contents
in an extra span, so that tooltips work for disabled elements.

This avoids a race condition: When the `excuse` is empty, but there's a
spinner, then the button is not formally disabled, but clicks go into
the void. This fixes the flaky TestStorageLuksDestructive.testLuks1Slots.

A normal user can't click on "Logout" while the modal superuser dialog
is open. Close the dialog first.

This worked because our `ph_mouse()` approach is cheating, but it won't
work when we do real clicks.

This was previously doing a wild mix of closing the upper (file-ac)
selector while the lower (file-ac-preselected) was already open, which
isn't something that a user can do with a real mouse (only with our
`ph_mouse()` fake API).

It also clicked around wildly without waiting for the changes, which was
racy.

Fix that by closing the upper selector first to conclude that check, and
then extend the clicks into the lower selector with comments what they
are supposed to do, and assertions what should happen after them.

The multiple clicks paper over a bug in that widget: The first time you
open it after the directory got created it still says "no such file or
directory", and only reloads after closing and re-opening it. We should
fix that, but not in this commit -- just capture the status quo.

When moving the mouse into the On/Off switch for clicking, the tooltip
appears. That lies on top of the kebab, which hence becomes not directly
clickable. Avoid that by moving the mouse out of the On/Off switch again
after clicking.

Don't remove the pop3 service simultaneously via the CLI *and* Cockpit
-- that's a clear race condition.

We already check that the UI reacts to `firewall-cmd --remove-service`,
so just drop that bit.

Clicking the popover in the advanced search form closes the whole form
with a real human mouse interaction, as well as with a simulated click
through BiDi. This doesn't happen with `ph_mouse()` though (so that
doesn't test reality).

This is some PatternFly bug, and not entirely obvious how to fix it. For
now, close the popover the same way as opening it, with the (i) icon.

Our years-old `ph_mouse()` helper is cheating: It completely side-steps
the browser UI and directly synthesizes `MouseEvent`s in JavaScript.
This allowed funny things like clicking on a main page element while a
dialog is open (which you can't normally do as the dialog is modal),
clicking an element which is disabled in some non-standard way, or
clicking through a tooltip.

Make this more realistic by using the BiDi API for synthesizing mouse
events. This works fine with Firefox, but is unfortunately completely
broken in iframes with Chromium:
https://issues.chromium.org/issues/359616812

Specifying precise coordinates is not currently implemented.
`ph_mouse()` always clicks on the top left corner, while webdriver's
`pointerMove` puts (0,0) in the center of the element. This can be done
with a little extra calculation of the `getBoundingRect()`, but only
very few tests like `TestStorageLvm2.testMaxLayoutGrowth` rely on that.
For these tests, continue to use `ph_mouse()`.

https://issues.redhat.com/browse/COCKPIT-1158