Refactor stanza parsing, add several new features

[bluemods]

Summary of changes:

• Message parsing is highly refactored, more simple, and more secure. recursive=False is used for finding child elements frequently as nested tags can be malicious.

• Since message parsing is improved and simplified, we can use the incoming messages themselves as arguments to sending receipts. This is a breaking change.

• Added block, unblock, mute, unmute, request list of muted chats

• Added roster request v9 support

• Added utility to check validity of JIDs

• Added ability to change profile pictures in groups (caller requires admin)

• Added retries for uploading profile pics on bad status code, this has started to fail on Kik's side a lot recently

• on_pong_response now has the latency calculated

• introduce server synced timestamps via KikServerClock. This is done the same way by mobile clients to keep timestamps in sync with the server when sending stanzas that contain them.

• 'kik:iq:friend' is only used for username requests, friend batch for JIDs.

• If more than 1 username is requested at once via request_info_of_users, the method will throw an exception. This is because Kik only allows 1 username to be retrieved per request. JIDs can be requested in batches of 50 via friend batch.

• Fixed some of the examples, which used the old logging parameter instead of the new enable_logging

• Fixed GetMyProfileResponse parsing

• Improved user and group parsing, we now use a common ProfilePic class.

[bluemods]

Something I forgot: the password and email methods have been fixed. The old methods were sending the old password along with the new one, this is wrong.

passkey-e means new email derived passkey, passkey-u means new username derived passkey.

passkey-e was being sent as the old password, which means that clients who sent the password this way only changed the password when logging in through the username, but clients logging in via email, the old password will still work.

This is a potential security issue affecting users of the client, as if you know the email and the old password, logging in can still succeed even though the username password was changed (though if you logged in this way via XMPP, you could not then establish an authenticated session since you still need the username passkey for that).

[tomer8007]

Thanks a lot for this pull request. It's a big refactor indeed. Did you check that all the messages whose serialization process was changed still work? A possible drawback of the new serialization way is that now it's harder to get an idea of how the XML looks like. This is why we have this page.

So if you have more stuff to add there, feel free to open an issue or so.

[bluemods]

There were some issues with parsing and typing not sending but I have resolved those.

A possible drawback of the new serialization way is that now it's harder to get an idea of how the XML looks like.

This is true but there are several major advantages:

• No longer vulnerable to XML injection in those areas
• significantly reduces boilerplate / reused code
• standardizes the serialization of messages so new formats can be added quickly

[tomer8007]

What do you think about adding a big comment next to each of the new serialization codes showing the form of the generated XML?

[bluemods]

What do you think about adding a big comment next to each of the new serialization codes showing the form of the generated XML?

I think that doing this bloats the code size and isn't necessary.

Users interested in how the XML packet looks when serialized should either check the log output which contains the stanza or consult the wiki and / or source code to see how they are generated. Preferably the wiki. Because if we include it into the code directly, it is being documented twice. I think the docs inside of the code itself should be describing the behavior / effects of the code, and the packets should be documented in the wiki.

Let me know what the best way is to contribute to that wiki.

[tomer8007]

Let me know what the best way is to contribute to that wiki.

I think I will turn the wiki into a file inside docs directory so that pull requests will be easier

[bluemods]

This PR should be complete, for now. Let me know if there's anything further that needs to be completed.

[tomer8007]

Again thanks for this great pull request. Anything else you want to commit before I merge?

[bluemods]

Again thanks for this great pull request. Anything else you want to commit before I merge?

I think this one is big enough. Additional changes / improvements (such as documentation discussed earlier) will be in new PRs.

[tomer8007]

I think I will turn the wiki into a file inside docs directory so that pull requests will be easier

Did this.