add pin message api

[r10s]

• add an api to pin/unpin a given message.

  • api takes at least the msg_id as parameter.
  • it is allowed to pin self or others messages, in one-to-one chats, in groups, in saved-messages.
  • send info message, "USER pinned a message", its parent is the rfc724_mid to be pinned. same for unpinning, however, that info message is not visible
  • receiving the info message fires an event or all members, that then know that pinning state has changed

• add an api to list pinned messages, so to get all pinned msg_id from a given chat_id. this api is used to show the pinned messages atop of the list

• add pinned/unpinned state (boolean) to message object; this is used to show a "pin needle" beside pinned messages.

we do not take care about resending pinned messages if someone join a group; this may or may not come later, maybe #7766 is good enough or even better privacy wise. for channels, we can resend pinned messages in addition to resending last 10 messages without many issues.
info messages themselves must not be be pinnable atm (as there do not have a shared rfc724_mid).

to not add complexity and to not have additional database calls or joins on getting messages, easiest way might be to have a "pinned" column in the msgs table.

once a PR is started, UI should be start implementing, one of android/iOS/desktop.

recent discussion in the forum https://support.delta.chat/t/2176/5

[link2xt]

to not add complexity and to not have additional database calls or joins on getting messages, easiest way might be to have a "pinned" column in the msgs table.

We do not use NULL, so I think adding new column with a default will store "unpinned" status for each message in the database unless there is some very specific optimization in SQLite, so adding a table with chat_id and msg_id is probably better than a column.

[r10s]

in case we want to have the pinned state being part of the message object returned by Message::load_from_db(), that would require a LEFT JOIN, which is probably more expensive than returning an additional column.

if we want to have an additional api for querying the state, an extra table seems fine, yes.

[missytake]

in case we want to have the pinned state being part of the message object returned by Message::load_from_db(), that would require a LEFT JOIN, which is probably more expensive than returning an additional column.

if we want to have an additional api for querying the state, an extra table seems fine, yes.

isn't it mostly useful as part of the Chat object? That a Chat links to the pinned Message objects? Not sure about all implications here, I'm thinking about the object-oriented deltachat-rpc-client here, the rust core isn't really object-oriented, right?

[r10s]

for chats in chatlist and mostly elsewhere, pinned attribute is not needed. but making the list of pinned messages part of chat would very likely include an additional database operation, and this is what the concerns are about.

might be minor, but otoh, messages and chats are loaded a lot