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.
First of all, because it shouldn't be doing that. Second, it was
buggy and was passing the tuple returned by get_input_location to
download_file which doesn't accept tuples (instead it should be
passed the photo object so that download_file could return dc_id
and input file location itself).
Plenty of unnecessary exceptions were being raised and caught when
the input parameters were already correct. Furthermore, since
8abc7ade22, the in-disk cache was no
longer being used (so using usernames always reached out to memory).
Previously it would take the first chat it found and use the IDs
of all messages, even if they belonged to different chats, resulting
in unexpected messages to be forwarded.
Another solution would be to check that all the chats are the same,
but this solves the issue more nicely and makes it more powerful.
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.
This would cause issues in _cache_media since utils.is_image fails
in the second pass (it respects the stream's position, and the user
may rightfully pass a stream that should be read only from one pos).
