Tweak main menu server list behavior

[siliconsniffer]

Add compact, short information about your PR for easier understanding:

This PR resolves some buggy behavior when searching or removing favorites.

• Goal of the PR
  Provide a more intuitive user experience when searching or deleting favorites.
• How does the PR work?
  It saves the current selection before searching so that it can be reused if a user should clear the search bar.
  When searching, it now also checks if the selected server is among the search results; if not, it will select the first compatible.
  Instead of keeping the selection when removing a server from favorites, now the selection will be moved to the server below.
• Does it resolve any reported issue?
  Fixes [Discussion] Behavior of parts of the main menu #15545
• Does this relate to a goal in the roadmap?
  2.3 hopefully

Preview

This PR:

Current Master:

How to test

Search servers (maybe the same as in the issue), remove favorites.
Notice how the selection is kept when clearing the search.

[appgurueu]

I would prefer a more narrow fix which specifically prevents the server selected after searching from being incompatible. So essentially just 1fefc3a, probably ideally without the possibly unwanted change of trying to keep the selection when searching.

The reason for this is that:

• The correctness of the "narrow" fix is easier to see.
• There is nothing to discuss about preferences: It is just a bugfix and can thus go into 5.11. Everyone can agree that selecting an incompatible server, putting you at the bottom of the compatible servers section, isn't helpful but just weird.

In particular, the pre_search_selection is somewhat problematic in my opinion, both in terms of UX and current implementation: I can have (explicitly) selected a many servers, but when I then clear my search, suddenly some server from a while ago I don't remember selecting will be selected again. I think that's an unexpected side effect.

(You can of course still PR the other changes, but I would treat them as "Request / Suggestion" rather than "Bugfix" PRs.)

[siliconsniffer]

Just to verify that I've got you right, you suggest splitting this up into two separate PRs? I agree that the "cosmetics" can be made into a separate PR, the core goal was to fix the broken search anyway. What would be the easiest route then? Leaving this open and repurposing it for the cosmetic suggestions while creating a new one with only the bug fix?

[appgurueu]

Just to verify that I've got you right, you suggest splitting this up into two separate PRs?

Yes

What would be the easiest route then? Leaving this open and repurposing it for the cosmetic suggestions while creating a new one with only the bug fix?

Either way is fine by me, the end result just needs to be that one PR contains precisely the bugfix while the other contains only the "cosmetics".

[siliconsniffer]

Split PR is open. Will rename/edit this one when the bug fix is merged/done. Edit: I think its fine as is.

[siliconsniffer]

Sorry, made a mess when trying to rebase.

[y5nw]

Tested and works:

• The last manual selection (incl. ones selected after searching) is used when resetting search.
• Adding a favorite keeps the server selected.
• Removing the favorite selects the next server in the favorites.

[SmallJoker]

Works.