RFR: 8332158: [XWayland] test/jdk/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java

[Alexander Zvegintsev]

There are two mouse pointer locations on Wayland:

`#1` Wayland compositor - can be controlled by a physical mouse device, or libei, this location is visible on a screen as a mouse cursor and is propagated to `#2`.

`#2` Inside the XWayland server - most of the time this is the same as `#1`, unless we have changed it programmatically, e.g. by using the XTest extension protocol, but it does not move the visible mouse cursor in `#1`.
Our tests in X11 compatibility mode using this approach(aka `java.awt.Robot#mouseMove`)

This test moves the mouse cursor to a specific location over a window in `#2`, which most likely isn't the same as the visible cursor location in `#1`.
If the window was moved/resized and placed under the visible cursor location, that cursor location is also set for `#2`, and from the test's perspective, the mouse has just been moved to a different location without the test expecting it, causing unexpected mouse enter/exit events.

We can try to smooth this out with additional `robot.mouseMove` calls, but it looks like we are missing the point of the test.
So for now it is better to skip the test on Wayland.

Another way is to use libei to move the visible mouse cursor on the system ([JDK-8280983](https://bugs.openjdk.org/browse/JDK-8280983)), but its support is not yet widespread on supported systems.

Testing looks good.

-------------

Commit messages:
 - 8332158: [XWayland] test/jdk/java/awt/Mouse/EnterExitEvents/ResizingFrameTest.java

Changes: https://git.openjdk.org/jdk/pull/20717/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20717&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8332158
  Stats: 15 lines in 2 files changed: 10 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20717.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20717/head:pull/20717

PR: https://git.openjdk.org/jdk/pull/20717