fix: mutating real messages due to "keep draft ID" logic

[WofWca]

Remember to hide whitespace for easier review.

Calling send_msg() with a draft message that was already sent
(by specifying msg.id)
would mutate that message in the DB and try to send it again.

do_set_draft has the same issue:
if the draft is sent in another Future
after get_draft but before sql.execute,
we would mutate that sent message in the DB.

Additionally, prepare_msg_raw now errors out
if the draft is not present in the database.
Previosuly the UPDATE query would simply update 0 rows
and we would proceed with trying to send a message
without having it in the msgs table.

The bug has been introduced in cf33db3
(#2887).

Semantically this makes prepare_msg_raw API less generic,
narrowing down its update_msg_id function only to drafts.
The "update draft" is anyway the only use case so far
for this parameter.
Thus this also removes the ability to specify an ID
that is different from msg.id, as was suggested in
#2887 (comment).
These IDs were always the same anyway.

Maybe it would make sense to, instead of returning an error
from send_msg if the draft is already sent or does not exist,
simply upsert a new message without looking at msg.id,
as we would do with non-draft msg.states,
but I wasn't sure how CFFI users (DC Android and DC iOS)
would take that.
So for now let's simply return an error instead of messing up the DB.

[r10s]

this PR is not understandable and too vague.

• it lacks a detailed, precise, summarised description about why it is needed and which real-life issue it solved
• the PR seems to mix adding features and fixing bugs
• it should not be up to reviewers to guess things and try to make sense of that by reading code or commit descriptions
• while bug fixes are of course welcome, first reflex of adding complexity as a new "draft policy" is that this will result in the opposite, more states, more discussions, more bugs
• one can assume by past, vague messages that it is about adding drafts to desktop, and about #8485 - but as there is no link nor comment, this is only a guess. as this issue is already outcome of previous discussion, please also comment there

[WofWca]

it lacks a detailed, precise, summarised description about why it is needed and which real-life issue it solved

It's a draft, I will udpate the description and clean up the commits.

the PR seems to mix adding features and fixing bugs

Not the case.

first reflex of adding complexity as a new "draft policy"

It's just a more explicit bool basically. And this results in less state, because I'm eliminating the message ID wrapped in Some from the argument.

one can assume by past, vague messages that it is about adding drafts to desktop

This is the stuff that I'd like to fix before implementing that feature, so that I don't have to introduce more of such bugs while implementing it.

[r10s]

It's a draft

this part i've overseen :)