Dan suca
If Dan shared it with Traitor I'll not have to spend my time on this
Not a, sorry for not letting you sleep
k thx bye
Will this stay in history?
This special check treated some emojies as 3 characters long but
this shouldn't have actually been done, likely due to the old
regex matching more things as emoji than it should (which would
have count as 2 too, making up for 1+3 from the new is_emoji()).
Likely since the code was ported to get rid of the BinaryWriter,
since the flag calculation was inlined. Some types (only
channelMessages as of layer 71) had a flag indicator but no flag
arguments, so the calculation of which were not None failed.
This special case is now handled correctly.
The reasoning behind this is that .connect() should not call
any request at all, it should only connect to the servers
although it currently still calls GetStateRequest.
There were some issues (#291, #360) where the auth_key was None
(possibly due to .connect() returning False), so this may
fix some of the cases where it returned False. This way we also
ensure that we always have an auth_key, or even if it "breaks"
(it's not the right key for the server anymore).
A few additional changes have been introduced to accommodate
this, such as moving InitConnection logic too or importing auths.
Every update that hadn't been acknowledged on the main connection
yet would be resent on any new connection. These new connections
are made temporary when invoking anything from any thread that's
not the main thread. It would also process all the updates, hence,
Telegram would be resending these not-acknowledged updates to the
temporary connection, and the updates would be processed again,
then the update handler would react to the duplicated updates over
and over.
To fix this, simply don't process updates on the temporary thread
at all. With this reasoning, if we don't acknowledge updates on
the temporary connections, Telegram will resend them on the main
connection, so we should not lose any.
