This issue would likely be triggered when automatically
merging multiple requests into a single one while having
their size exceed 1044456 bytes like SaveFilePartRequest.
This commit avoids such issue by keeping track of the
current size, and if it exceeds the limit, avoid merge.
This has several benefits:
- The message can be resent without re-calling bytes(),
which for some requests may be expensive.
- Converting requests to bytes early lets us detect
errors early, such as OverflowError on bad requests.
- Containers can't exceed 1044456 bytes so knowing their
length is important. This can now be done in O(1).
But also several drawbacks:
- If the object is modified the bytes won't reflect this.
This isn't an issue because it's only done for in msgs.
- Incoming messages can no longer be reconverted into
bytes but this was never needed anyway.
It would cause issues with the debug logs, since it assumes it's
a TLMessage, which have an .obj attribute. Second, the send_loop
is also smarter regarding reconnects (since OSError often occur
due to not being connected at all, namely ConnectionResetError).
Otherwise the program could potentially block on await client(...)
since this has no timeout (unless asyncio.wait_for() was used) and
would give no further hint that the program was halted there.
There's 12..1024 padding for the MTProto 2.0 protocol, and
the length of the message can be used to determine how much
must be read on rpc_results. However this random padding
can be safely ignored.
This simplifies the flow instead of having separate request/body
attributes, and also means that BinaryReader.tgread_object() can
be used without so many special cases.
