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.
This reverts commit 280a700655.
The reason for this is that it was causing a lot of files to
be downloaded corrupted for some reason. This should be
revisited to avoid creating a new connection for every chunk.
Calling this method on exported clients would trigger a
UserMigrateError because it was being used on a non-native
data center. For .connects like this, don't attempt syncing
updates.
Rationale: the intended behaviour of the TelegramClient will now
be to focus on abstracting the users from manually importing
requests and types to work with Telegram's API. Thus, all the
core functionality has been moved to the TelegramBareClient,
which will now be responsible of spawning new threads or
connections and even handling updates.
This way there is a clear distinction between the two clients,
TelegramClient is the one meant to be exposed to the end user,
since it provides all the mentioned abstractions, while the
TelegramBareClient is the "basic" client needed to work with
the API in a comfortable way.
There is still a need for an MtProtoSender, which still even
lower level, and knows as little as possible of what requests
are. This handles parsing the messages received from the
server so that their result can be understood.
