Because Telegram can't actually use 0 for the pts, it uses 1, even
if the count is 0. This forces the next update to use 2, or else it
could not be fetched when using an offset of 1 (despite the count
being 0 on the first update, which should not have bumped the second
update to use 2).
This caused Telethon to create an initial state of 0 for the new entry
(and also "incorrectly" detected following updates as gaps, which
would quickly trigger the call to get difference with a bad pts).
Now Telethon is aware of this special-case and will not initialize
state as 0, even if that's not the "correct" thing to do.
These will log sensitive information.
They are disabled when running with PYTHONOPTIMIZED.
They can only be enabled by setting a level lower than DEBUG,
which is difficult to do on accident.
Closes#3936.
There are two changes made to ensure the first update in a channel
cannot be lost, first by always sorting updates before applying pts,
and second by cautiously initializing the local pts if the client
had no pts known beforehand.
It might be possible to cleanup the handling of possible gaps now
that updates are always sorted, but that requires more thought.
This probably occurs with bot accounts only.
It is strange that the qts is used by bots but is missing from the
results of getDifference. This would need more investigation, but
it might just be the way this thing works.
Closes#3873.
Follow-up to 876af8f27c.
The issue was caused because we called end_get_diff to cleanup a diff
that could not actually be started.
This also enables further cleanup later on.
