When a bot account sends a message, deletes it, and sends a new one,
very reliably it would detect a gap, and as a result recover the
second message it sent, processing it itself (because the hack with
`_self_outgoing` cannot possibly work when catching up).
Now certain `rpc_result` are also processed as-if they were updates
(including the ones from deleting messages), which solves this gap
issue. Not entirely sure if it's a hack or the intended way to do it
(since Telegram *does* return proper `updates` for other RPCs), but
it seems to solve this particular problem.
Other requests such as reading history, mentions or reactions also
return an instance of this type, but the `pts_count` should be 0,
and at worst it should simply trigger a gap, which shouldn't be a
big deal.
This behaviour is deprecated and will be removed in future versions
of Python. Technically, it could be considered a bug (invalid usage
causing different behaviour from the expected one), and in practice
it should not break much code (because .get_event_loop() would likely
be the same event loop anyway).
This will help unifying the retry loop and reconnecting
if the server disconnects us during auth key generation
which will be done in a follow-up commit.
Which leads to "RuntimeError: readexactly() called while another
coroutine is already waiting for incoming data" being raised,
and causing everything to break or halt.
This way it is easy and cheap to copy the two required values
to all incoming updates in case we need to getDifference since
the previous pts/date to fetch entities.
This is still a work in progress.
It's the only way to properly clean all background tasks,
which the library makes heavy use for in MTProto/Connection
send and receive loops.
Some parts of the code even relied on the fact that it was
asynchronous (it used to return a future so you could await
it and not be breaking).
It's automatically syncified to reduce the damage of being
a breaking change.
* Create `_NOT_A_REQUEST` when needed. Currently, modifications
in the raised exception would be "global".
* `retries` parameters were actually attempts. This has been fixed
to actually be the amount of retries, so 0 now means don't retry.
* Helper function to deal with retries instead of using a range with
different styles every time.
The idea behind distinguishing between the user being connected and
the actual connection having been made was to support retries while
the user decided to connect, even if the connection wasn't made yet.
The problem is that _user_connected is used directly to tell whether
the sender is connected or not which will be wrong if an exception
occurs on the initial connection. Since the logic retry isn't used
there we can simply mark as connected once a successfull connection
is made.
