Add support for message reply

[Kaffeine]

Add a new message header keys:

• reply-to-message-token (s) An opaque identifier of the original message, as used by the underlying protocol.

[Kaffeine]

@gkiagia Do you know why we have the "as used by the underlying protocol" text everywhere (starts from [1])?
In my opinion, it should be OK for CM to use any message token format. E.g. message can contain some channel id.

In Telegram we have "message tokens", that (after some upgrade two years ago) are not globally unique, but in the CM I want to concatenate channel and message IDs (tokens) to uniquely address them.

[1] https://telepathy.freedesktop.org/spec/Channel_Interface_Messages.html#Simple-Type:Message_Header_Key

[detrout]

Grepping about message-token lead me to some comments that suggested there were some pain points. No idea why the CM doesn't synthesize a unique token though.

I found this in gabble

• Following telepathy-spec 0.21.5, the message-token field in message headers
is no longer guaranteed to be globally-unique. This is known to be
problematic for rtcom-event-logger, as used in Maemo 5.

And this in rakia

NOTE: some existing clients logging messages, notably the one released
in Maemo 5, make unrealistically strict assumptions about the uniqueness of
'message-token' values. These logging implementations may exhibit problems
with handling collisions in token values if used with this or later versions
of Telpathy-SofiaSIP. Such collisions are unlikely, but possible if a
remote endpoint generating the SIP Call-ID headers does not use an algorithm
compliant with the SIP specification to provide sufficient uniqueness.

[Kaffeine]

An open question is how to let a client know that a channel supports replies? Add an org.freedesktop.Telepathy.Channel.Interface.Reply Text channel interface?
(same story for message forwarding support)

[Kaffeine]

Some protocols include the original message, so the incoming raw message content looks like this:

"content": {
    "body": "Reply to Juliet\n>Art thou not Romeo, and a Montague?\n\nNeither, fair saint, if either thee dislike.",
    "format": "org.matrix.custom.html",
    "formatted_body": "<i><a href=\"https://matrix.to/#/!aAaaASAOSk:gazizova.net/$114522020523979WqwKg:host.io\">Reply to Juliet</a>:</i><br /><blockquote>Art thou not Romeo, and a Montague?</blockquote><p>Neither, fair saint, if either thee dislike.</p>",
    "msgtype": "m.text"
}

Is it a sane idea to split the message onto alternatives to let a Telepathy client to arbitrary format a reply message?

{ 'alternative': 'reply_to',
  'content-type': 'text/plain',
  'content': 'Juliet',
  'interface': 'org.freedesktop.Telepathy.Channel.Interface.Reply',
},
{ 'alternative': 'reply_to',
  'content-type': 'text/plain',
  'content': 'Reply to Juliet:\n',
},

{ 'alternative': 'quote',
  'content-type': 'text/plain',
  'content': 'Art thou not Romeo, and a Montague?',
  'interface': 'org.freedesktop.Telepathy.Channel.Interface.Reply',
},
{ 'alternative': 'quote',
  'content-type': 'text/plain',
  'content': '>Art thou not Romeo, and a Montague?\n',
},

{
  'content-type': 'text/plain',
  'content': 'Neither, fair saint, if either thee dislike.',
},

[gkiagia]

Agreed about the Ch.I.Reply and the message splitting definitely makes sense, but maybe you should be providing a full pre-formatted plain text version (like "body" in matrix) for clients that do not understand this splitting? I'm not sure how these alternatives are composed together in a dummy client. If it works, no problem.

About the uniqueness of the message-token, I don't know the background. Making a unique token in the CM sounds reasonable to me and I don't see why not do it.