JSON-RPC provide_backup call cannot be used reliably

[link2xt]

There is a race condition in typical usage
of provide_backup and get_backup_qr/get_backup_qr_svg JSON-RPC APIs.

Desktop usage is here:
https://github.com/deltachat/deltachat-desktop/blob/828f472a433a56bd77c25cb6f2aebcc556828b36/src/renderer/components/dialogs/SetupMultiDevice/SendBackupDialog.tsx#L87-L89

provide_backup only returns once backup is completely transferred,
so it is called asynchronously.
Then get_backup_qr or get_backup_qr_svg is called,
but these functions return "No backup being provided" error
if provide_backup has not created ProviderQr yet.

C API does not have such problem,
there backup provider is created with
dc_backup_provider_new and then used
by dc_backup_provider_get_qr
and dc_backup_provider_get_qr_svg.
dc_backup_provider_get_qr
and dc_backup_provider_get_qr_svg
cannot fail because BackupProvider
always exist when they are called.

Minimal change that does not require API changes would be
to make get_backup_qr and get_backup_qr_svg block
until there is a provider available.

[Simon-Laux]

I think going for the minimal api change makes sense, those calls already wait until the preparation is done anyway.

On the other hand it could be confusing for client/bot devs that don't read documentation if it blocks instead of returning an error when you haven't called provide_backup yet.

[link2xt]

I will try to fix it by blocking in get_backup_qr.

[link2xt]

I made a PR that makes get_backup_qr always block until there is a QR code even if provide_backup has not started yet: #5439
But there is a problem with this approach that we deadlock if provide_backup fails:
#5439 (comment)