[datlechin]

Summary

• A sidebar search and each new table list pick their rows on a blocking thread (SidebarRows). The list takes them in one change and drops rows that a newer search or list overtook, as the completion's ProposalList does.
• The index a new list replaces, overtaken rows and a stale SidebarRead are freed on the blocking pool: 6 to 17 ms of GTK thread for 50,000 tables in a debug build.
• Row tracking prunes rows that are gone only when its vector would grow, not on each of the ~200 rows a search sets up (2 ms per search).
• SidebarView::new takes Option<Tasks>. Without them, as in the unit tests, the rows are worked out on the GTK thread.
• What a search still costs the GTK thread is GtkListView replacing the ~200 rows around its anchor, plus a frame. That cost is the same with 2,000 tables as with 50,000.

Test plan

• Probe, 50,000 tables, debug build: set_query on the GTK thread went from 15 to 40 ms to under 0.1 ms. Search stall with 2,000 tables: 11 to 37 ms. With 50,000: 22 to 39 ms.
• large_catalog::mysql_database_of_50000_tables_lists_searches_and_completes, stall for i / in / "":
  • before, CI (feat(search): find a value in every table of a database #3737): 106.1 / 25.6 / 23.3 ms, GTK-thread CPU 41.6 / 36.4 / 33.2 ms
  • after, CI (this PR): 18.6 / 13.9 / 13.4 ms, GTK-thread CPU 23.2 / 21.9 / 21.2 ms. PostgreSQL: 19.3 / 17.6 / 15.6 ms, was 29.9 / 28.9 / 27.1
  • before, local: 33.8 / 27.8 / 15.9 and 27.2 / 16.6 / 13.9 ms
  • after, local, 5 runs: 15.3 / 11.9 / 12.8, 16.9 / 33.3 / 11.8, 26.9 / 23.3 / 18.6, 29.8 / 34.5 / 27.8 and 28.1 / 29.2 / 24.7 ms (the last one with the host swapping)
• New tests: a_list_and_its_searches_are_worked_out_off_the_gtk_thread and rows_worked_out_for_an_older_list_or_search_are_dropped.
• The list and model unit tests call the new API. Their assertions are unchanged.
• No changelog fragment. The unreleased linux/changelog.d/3729.fixed.md already covers the sidebar freeze.

Refs #3660