input/seatop_default: focus view on workspace switch

[smlx]

When focus_follows_mouse is enabled and the cursor moves from one
output to a layer surface (such as swaybar) on another output, Sway
would previously focus the workspace node.

This change updates workspace switching using either the mouse or
workspace_switch to use seat_get_focus_inactive_view first, ensuring
that the previously focused view on the target workspace receives focus.

Fixes: #8177

[smlx]

Reproduction steps for the bug this fixes:

1. have two outputs logically adjacent.
2. have swaybar in the same position on both (e.g. top or bottom) so that swaybar surfaces are logically adjacent.
3. open multiple tiled windows on both outputs.
4. move mouse onto swaybar on one output, then directly onto swaybar on the other output.

On master: the workspace node is focused, so all tiled windows gain blue "active focus" decorations but none have keyboard focus.

With this patch: the previously focused window on that workspace is focused.

This is reproducible in a nested sway session.

[emersion]

Do we really need a fallback mechanism? Or would it be enough to change this to current->node == node || node_has_ancestor(current->node, node)?

[smlx]

Hmm. I tested both the fallback mechanism and your suggestion and compared it to i3, and neither matches i3's behaviour. I'll rework it.

[smlx]

I drastically changed the way this patch was implemented and simplified it. From observing i3's behaviour I was previously was trying to fall back to focused descendants.

However after more testing I now realise that i3 is quite aggressive about focusing views only, and not containers. So there is no need to change the way that seat_get_focus_inactive works. Instead now the patch just calls seat_get_focus_inactive_view first, and falls back to seat_get_focus_inactive during a workspace switch.

As far as I can tell, this matches i3's behaviour in this area exactly.