Ensure dc_backup_provider_new behaves well when cancelled

[flub]

For the UI it is fairly normal that the dc_backup_provider_new() call is cancelled: the user might hit the back button which happens fairly commonly.

There are reports that sometimes it then takes a while for things to be cleared up and immediately calling dc_backup_provider_new() after cancelling makes it fail. Figure this out and make it work nicely.

[flub]

I've been poking at this and not finding anything. The only thing I can manage to get is that the ongoing processs has not been freed yet when calling the second prepare: but about 16-17 miliseconds after requesting the stop it is freed and a new process can start. This simply seems to be the time it takes to do those things, it involves acquiring some locks.

@r10s do you have any more hints about what problems exactly you see? How to reproduce?

[link2xt]

I have a desktop using the latest core 04daff0 and using desktop PR deltachat/deltachat-desktop#3150 for the UI (specifically commit deltachat/deltachat-desktop@7860cf4). On my Android phone I have an almost up-to-date self-built APK using core 83af248.

I have started offering a backup from Desktop and scanned the QR code using the phone. Backup transfer started, but looked slow to me, so I decided to try another Wi-Fi network. I cancelled backup transfer (likely from the phone, but not sure) and switched both devices to another Wi-Fi network.

Then I tried to start the backup transfer again, showed new QR code from the desktop and scanned it from the phone. The phone was forever trying to connect. I opened the log and looked at the IP address the phone was trying to use: it was correct, I verified by running ip addr on my laptop. Then I tried to cancel connection attempt and generate a new QR code, but failed to transfer again. However, after restarting the Desktop app and starting from scratch, I successfully transferred the backup.

I did not check whether desktop was really listening on the port (should have checked ss -lun or something like this), but it looks like desktop indeed got stuck in an incorrect state where it did not listen or did not respond to connection requests anymore until I restarted the whole app.

[link2xt]

Is it fixed by #4249?

[flub]

Is it fixed by #4249?

I think it's part of it. But I'm not yet confident enough it fixes the entire issue and want to try do more testing.

[r10s]

for larger account, i can still reproduce the following on core 112.4, tested on ios:

• tap "Settings / Add Second Device"
• during "prepare", hit "cancel" and confirm abort
• immediately hit "Add Second Device" again

-> Error: "there is already another ongoing process"

if you wait a bit after the error (no need to quit the app), you succeed in getting the qr code again (iirc, this was not possible on first tries, so things already got better :)

i could not reproduce that on smaller accounts. the following video is on a multi-gb account:

RPReplay_Final1680382983.mov

[flub]

So that certainly sounds like it is an improvement. There is always going to be some delay. The ongoing mechanism in core allows for some time before you release the ongoing process, as long as that's not more than a few seconds that should be fine. At least that's how it is currently designed.

I guess UX wise that complicates things though, there's no API to wait until the ongoing process is released. With how the ongoing process is designed now (in core) the UI should probably show something like "cancelling, please stand by..." after stopping the ongoing process and once it is freed you can then start doing things again. This also helps with other things, as e.g. the paused IO needs to be resumed again etc. This can't be instantaneous.

[flub]

So from my core-centric point of view what is missing is an API to wait until core has freed the ongoing process after cancelling/stopping it. Maybe this can be done by making stop_ongoing a blocking call?

[flub]

#4289 adds logging to see how long it really takes to between stop ongoing and free ongoing.