There are still a few things to change, like cleaning up the
code and actually caching the entities as a whole (currently,
although the username/phone/name can be used to fetch their
input version which is an improvement, their full version
needs to be re-fetched. Maybe it's a good thing though?)
Before:
First call, force_sms=False: SendCodeRequest
Next call, force_sms=False: SendCodeRequest
First call, force_sms=True: raise ValueError
Next call, force_sms=True: ResendCodeRequest
That's inconvenient because the user must remember whether the code requested at all and whether the request was successful.
In addition, the repeated invocation of SendCodeRequest does nothing.
This commit changes logic to this:
First call, force_sms=False: SendCodeRequest
Next call, force_sms=False: ResendCodeRequest
First call, force_sms=True: SendCodeRequest, ResendCodeRequest
Next call, force_sms=True: ResendCodeRequest
Rationale: the intended behaviour of the TelegramClient will now
be to focus on abstracting the users from manually importing
requests and types to work with Telegram's API. Thus, all the
core functionality has been moved to the TelegramBareClient,
which will now be responsible of spawning new threads or
connections and even handling updates.
This way there is a clear distinction between the two clients,
TelegramClient is the one meant to be exposed to the end user,
since it provides all the mentioned abstractions, while the
TelegramBareClient is the "basic" client needed to work with
the API in a comfortable way.
There is still a need for an MtProtoSender, which still even
lower level, and knows as little as possible of what requests
are. This handles parsing the messages received from the
server so that their result can be understood.
