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).
We rely on >= 0 for setting the batch size to use (which must
be valid), so it makes sense to make negative limits equal 0.
This is similar to how asyncio.sleep(negative) sleeps 0 seconds,
despite the fact that time.sleep(negative) fails.
This should make it easier to maintain these methods, increase
reusability, and get rid of the async_generator dependency.
In the future, people could use this to more easily deal with
raw API themselves.
This one in particular may happen when iterating over messages,
perhaps more likely to happen if the group was created in a
different data center.
A small sleep of a few seconds also greatly increases the
chances of the error going away.
It was actually using FileLocation, which had the invalid expected
type for what was being returned. Instead it should have been this
other type.
In addition, more parameters are passed so that the method can have
all the information it needs to correctly cast the type.
