feat(message-row): Add initial support for replies chat

[alissonlauffer]

This PR adds basic support for the "Replies" chat.

Things like showing replied messages and a button to view the original message should be addressed in other issues.

Closes #465.

[melix99]

Does it have two ids?

[alissonlauffer]

The second id is there because the second id is of the test backend bot.
This is also the same way Telegram Desktop implements it (with the exception that it also checks the current backend, but imo it's not needed): https://github.com/telegramdesktop/tdesktop/blob/41d9a9fcbd0c809c60ddbd9350791b1436aff7d9/Telegram/SourceFiles/data/data_peer.cpp#L891

[marhkb]

@alissonlauffer Could one of the ids collide with a regular chat? I would suggest to use this

pub(crate) fn is_replies_chat(&self) -> bool {
        (self.session_().client_().database_info().0.use_test_dc && self.id() == 708513)
            || self.id() == 1271266957
}

[alissonlauffer]

Well, actually, Marco suggested to handle UpdateOption instead (which includes a replies_bot_chat_id option), but I'm not sure how to correctly add support to tdlib options, since keys are just strings, and values can be of any type. Tdlib options are a nice thing to have in the session object, but it could be implemented in another PR, which could be merged before this one.

[marhkb]

You mean basically?

[alissonlauffer]

Yes, but we would need too much "boilerplate code" to do that, in my opinion.
But we can add tdlib options on demand also, there's no need to add all of them right away.

[marhkb]

we can add tdlib options on demand also.

What do you mean?

[alissonlauffer]

I mean, right now we would only require replies_bot_chat_id, but in the future, if we need more options, we could add one by one. But yeah, this could become an excuse for not using them.

[marhkb]

Yes, at Some point we should start using them. 😆
I think using this option is the correct future-proof way, as we never know whether telegram might suddenly change such a magic id.