Use coroutines to run dialogs asynchronously

[andy128k]

I'll be honest. I have no idea if this works properly. Few AIs helped me to craft this code. Generally, I'd like to have something like async/await in Rust, so I gave it a try.

[mvo5]

I have not looked in detail but I would be very hesitant here, its an interesting idea and probably fun to play with - but staying as close as possible to gtk is preferable IMHO. I have a hard time maintaining this as is so anything that adds burden feels not ideal. Sorry if that sounds disappointing.

[andy128k]

@mvo5 I totally understand your point. The piece of code in this PR is awful (in a part where coroutines are defined). I don't mind if this PR will be rejected. I'd just want to clarify the future direction, so, I could contribute to the project.

---

The problem with sticking to Gtk is that Gtk4 does not have synchronous dialog API anymore. See https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-blocking-dialog-functions

So, all the places which use dialogs and gtk_dialog_run (not even saying about gtk_events_pending) needs to be fully reworked. That'd be a major rewrite of the whole application.

It'll be not possible to have functions like bool RGUserDialog::showError() anymore. Any time a function needs to show a dialog (e.g. get user's consent) it needs to be split into two functions and pass an intermediate state (stack variables) somehow from one to another.

The point of using coroutines is that application's code may still look the same (or resemble the original code) but be asynchronous. In this PR co_await co_run_dialog() is where gtk_dialog_run used to be.

I've mentioned Rust above, so, Gtk-rs solves this by wrapping signals and running futures (coroutines) on top of Glib event loop. See gtk::Dialog::run_future.

I successfully used Rust async functions in a few rewrites from C++/Gtk3 to Rust/Gtk4. So, I gave C++ coroutines a try to replicate the pattern.

[andy128k]

What about converting to Rust?

[andy128k]

This PR evolved a bit.

• Now it uses beman::task (a reference implementation of std::execution in C++26).
• All operations which may be interspersed with user interaction are coroutines now.
• All problematic calls like gtk_main, gtk_events_pending, gtk_main_iteration are replaced by suspends.

[julian-klode]

Generally speaking synaptic is built around the glib/gtk ecosystem which operates with a main event loop in a fully asynchronous (but single threaded) fashion.

To interface with APT you want to have a single apt thread or process and message queues to the main thread glib event loop. Importantly you may never call APT functions from different threads.

Vendoring a third-party library is violating general expectations on Debian software.

Overall there is not much point in this work. As bad as this sounds synaptic in the end needs to migrate to a multi-process architecture anyway where the privileged operations are clearly separated from the user space components.

The architecture of the APT daemon is an ongoing process of intermittent thoughts :D