Borrowed senders are not disconnected immediately, but after a while.
If a borrow was used recently but the user requested the main client
to disconnect, those borrows "shouldn't" disconnect because they were
used recently. However, if the user requests a disconnect, they mean
that EVERYTHING should be disconnected, even if the borrows are recent.
This actually gets rid of warnings about send/recv tasks being destroyed,
which partially addresses #1634. That issue may still have more causes
though.
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).
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.
Destructors are not guaranteed to run. Despite having good
intentions (saving entities even if the user forgets), it
should be the user's responsability to cleanly close the
client under any circumstances.
Excepting ValueError when creating the SQLiteSession could hide
other errors (e.g. using a newer session file on an older version
of the library). Instead, the original error is raised, as if
sqlite3 was being imported within its __init__ method.
* 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.
