`stop_ongoing()` doesn't work if called too soon

[WofWca]

• Operating System (Linux/Mac/Windows/iOS/Android): All
• Core Version: 2.59.0
• Client Version: 2.59.1

Expected behavior

add_transport is cancelled.

Actual behavior

core/src/context.rs

Line 821 in 2cacdbf

info!(self, "No ongoing process to stop.",);

In practice this means that pressing "Cancel" doesn't actually cancel anything.

Steps to reproduce the problem

1. Call rpc.add_transport_from_qr
2. Immediately (or almost immediately) call stop_ongoing_process.

The problem is that there are quite a few awaits before the alloc_ongoing.

core/src/configure.rs

Line 133 in fbbe56c

let cancel_channel = self.alloc_ongoing().await?;

The biggest one is probably stop_io

core/src/configure.rs

Line 160 in fbbe56c

self.stop_io().await;

This bug definitely affects Desktop

https://github.com/deltachat/deltachat-desktop/blob/820deb5fcb0b0f350fce1041122dddad60196948/packages/frontend/src/components/dialogs/ConfigureProgressDialog.tsx#L65-L88

And most likely also Android, but I didn't try:

https://github.com/deltachat/deltachat-android/blob/8a389bdf24c773fc7153bc86088316bdeaa952cb/src/main/java/org/thoughtcrime/securesms/InstantOnboardingActivity.java#L583-L598

I see two options:

• Redesign the API. Such that the user can stop a process by its revocation handle / token / signal. Can be either a parameter provided to add_transport or its return value (although add_transport doesn't return until it's finished).
• Offload the problem to users (client devs). Tell them in the docs that they need to wait for at least one ConfigureProgress (or whatever else) event before they can call stop_ongoing.

[link2xt]

Redesign the API. Such that the user can stop a process by its revocation handle / token / signal. Can be either a parameter provided to add_transport or its return value (although add_transport doesn't return until it's finished).

It has to be a separate API to allocate cancellation token ID that is then passed back into add_transport and similar functions (import/export etc.) that can then be cancelled.

Offload the problem to users (client devs). Tell them in the docs that they need to wait for at least one ConfigureProgress (or whatever else) event before they can call stop_ongoing.

I guess #8627 is about this second option.
It was probably intended to be this way to avoid complex stateful "waiting for the first event" logic. Cancel button only sends stop_ongoing(), but the dialog is closed once the final ConfigureProgress event is received and not when the button is clicked, so worst case the user has to click second time. But this should of course happen very rarely, so if alloc_ongoing happens late then you get bad UI that forgets you clicked the button.