feat: Use random filename suffixes for blobstorage (#4309)

[iequidoo]

This is split out of #4583 for easier reviewing.

Recently there was an accident with a chatbot that replaced its avatar set from the command line with an unrelated avatar of a contact. Both the selfavatar setting and the contact avatar i param pointed to $BLOBDIR/avatar.png at the time it was detected. How this happened is unclear, but it is possible that avatar.png was removed, unmounted or otherwise not detected by the core, and the core stored avatar received from the contact as avatar.png, while selfavatar config still pointed to $BLOBDIR/avatar.png.

Such bugs are unavoidable even if the core itself has no bugs as we cannot rely on blobdir not reside on the faulty network filesystem, being incorrectly backed up and restored etc., so we should assume that files may be randomly removed. Then there may be dangling $BLOBDIR/... references in the database which may accidentally point to unrelated files, could even be an avatar.png file sent to the bot in private.

To prevent such bugs, we add random filename suffixes for the blobdir objects. Thanks to the added Param::Filename these random suffixes aren't sent over the network.

[r10s]

lgtm, functionality wise, thanks! imu, the PR just always adds a suffix to the stem, not just sometimes (please correct me if i summed that up wrongly :)

i think, this is a reasonable way forward to get rid if weird filenames. however, i leave code-level review to ppl who are more into rust and python.

deltachat.h still says "File name may be mangled" - but that should be "File name will be mangled", or?

wondering what is left in #4583 - i am a little confused by the the two PR :)

ideally, before this gets merged, imu UIs should check their usage of dc_msg_get_file() and change "affected" code to BLOBDATA+dc_msg_get_filename() or dc_msg_save_file() - again imu, UIs can test that already now by forcing a suffix by sending the same file twice
@iequidoo can you please check/refine and file issues for that in all UIs? this is useful in any case

[iequidoo]

imu, the PR just always adds a suffix to the stem, not just sometimes

Exactly

deltachat.h still says "File name may be mangled" - but that should be "File name will be mangled", or?

Yes, forgot to move the documentation changes to this PR from the follow-up one.
EDIT: Done.

wondering what is left in #4583 - i am a little confused by the the two PR :)

It removes the original file stem at all, we don't need it as we have dc_msg_get_filename() and the app should use it when exporting attachments (maybe not only, but at least). And also the next PR fixes #5338.

It's still a question what to do if we need to display a file (with random name) in some external program. This could be solved by preserving file names, but storing files in dirs having random names to avoid copying. But afaik there are plans to encrypt the whole blobstorage (especially on Desktop because there's no sandboxing), so copying can't be avoided anyway.

ideally, before this gets merged, imu UIs should check their usage of dc_msg_get_file() and change "affected" code to BLOBDATA+dc_msg_get_filename() or dc_msg_save_file() - again imu, UIs can test that already now by forcing a suffix by sending the same file twice
@iequidoo can you please check/refine and file issues for that in all UIs? this is useful in any case

I think this one can be merged even before switching all UIs to the new API (though it can break sending multipart archives as @adbenitez noted), but definitely not the next PR. I can check Desktop and Android on my own, maybe also iOS, but i don't use it and never looked into its sources :)

[iequidoo]

So far i see the following tasks for the UIs:

• Android: switch to using dc_msg_save_file() for saving attachments.
• Desktop: the same (jsonrpc's save_msg_file()).

(I'm going to file tasks, but need to study the apps code a bit more)
But they look unrelated to the PR so it can be merged. The more important question is

... what to do if we need to display a file (with random name) in some external program. This could be solved by preserving file names, but storing files in dirs having random names to avoid copying. But afaik there are plans to encrypt the whole blobstorage (especially on Desktop because there's no sandboxing), so copying can't be avoided anyway.