`receive_imf_inner()` shouldn't fail for partial downloads

[iequidoo]

This is a follow-up to #7290 . Currently receive_imf has many is_partial_download.is_{none,some}() checks and apparently there are places where such checks are forgotten (and it's not really achievable to ensure that this will never happen in the future), so sometimes logic aimed for processing fully downloaded messages is executed for partial downloads, this may lead to inconsistencies and if a logic error happens for a partial download, it can't be added to the chat and the IMAP loop will stuck, see f94b2c3. A possible solution is to only parse some minimum set of headers in mimeparser for partial downloads, like Message-ID, Chat-Group-Id so that a partial download can be added to the chat but nothing else happens, and remove is_partial_download checks from receive_imf where possible.

[hpk42]

Don't think it's neccessary to refine current partial downloads. It's planned to revise how download-on-demand is implemented by sending a small pre-message ahead of any larger message. Most of the special is_partial_download code should then vanish some time after Pre-Message support is rolled out.

[iequidoo]

Partially downloaded messages can still arrive w/o any pre-message because we can't drop support of receiving large messages sent by other MUA (i guess). Also a pre-message may be lost, this is unlikely, but we shouldn't just drop the following large partially downloaded message w/o displaying some stub and allowing to download it as currently. So while pre-messages help to display large message nicely (e.g. by displaying a thumbnail) and add them to the right chat, they don't solve the issue completely.