allow forwarding messages to other profiles

[r10s]

this issue is discussed as being "lowhanging UX fruits with few core effort",
once this is targeted a counterpart UI PR should be done

the current dc_forward_msgs takes a list of messages and a destination chat-id.

this issue is about enhancing/recreating the api to allow forwarding to a different profile.

the api would take:

• a source profile-ID
• a list of source message-IDs, if needed we can assume, they're all from the same chat
• a destination profile-ID
• a destination chat-ID

it seems fine if the new api is added to jsonrpc only.

not sure, how easy this is to do, iirc, we never had a cross-profile usage before.

if that gets too complex, we can think over alternatives, but for now, let's check if the above is doable

[Simon-Laux]

I wonder what should be included in forwarded messages:
anything more than copy text & attachment and attaching a "forwarded" label?
What could core do that the UI can not already do, besides adding the "forwarded" label?

[r10s]

yes, it is about the forward label and removing data we do not want to forward.

iirc also ordering is guaranteed to be intact, even if there are more messages than seconds available for "time smearing".

maybe there is more, i did not look at the code.

the "forward" label cannot be set by ui, and it is also handy to just call the forward function with a list of message ids instead of reading and construnction message objects and sending them manually

this also guarantees same forward behavior on all ui

[iequidoo]

I think we should improve the message forwarding code, we always forget to remove some params/headers as this can't be catched by existing tests, some examples:
bfc08ab
a1837ae
56b2361
...
This may leak confidential data. Instead, it's better to explicitly list params that we want to forward, then if we forget to forward some param, a test on forwarding messages carrying the new functionality will break, or the bug will be reported earlier, it's easier to notice that some info is missing than some extra info is leaked. Maybe even iterate over all params and match on them, then the compiler will remind if we forget to handle a new param.