Correctly connect to DC203/CDN

[9seconds]

There is long-standing issue that Telegram CDNs are not publicly enlisted. So, when it requests for DC203 (CDN), mtg had no idea where to look at. Apparently, it works this way:

1. Telegram client logins into Telegram
2. It requests a configuration from a server using help.getConfig RPC method.
3. This method returns a list of everything that is required for a client: DC ips, ports, obfuscation preferences, secrets etc.
4. CDN IPs are also retrieved with this method.

Unfortunately, Telegram does not rely on DNS (this is probably a good idea), so we cannot use any permalink here. Moreover, CDN IPs are very specific to each client, so hardcoding them works as a cat'n'mouse game. Since CDNs are specific to client settings (regions etc), they are not returned with anonymous help.getConfig request. We can do nothing about it.

What works at least now is using a single IP that was extracted by logged in user. This works so far, but this is not a complete solution by any mean.

The best thing we can do is suggesting users ways to do their own overrides, so they can specify their IPs. This is configurable:

# Telegram uses different DCs for different purposes. Unfortunately, most of
# DCs are not public, and dependent on a location of the current user, so
# mtg cannot know upfront about all of them, and how to access them. It has
# a default list of DCs, including some CDN IPs, but it is possible that some
# of them are not working for you. In this case, you can override them here.
[[dc-overrides]]
dc = 101
ips = ["127.0.0.1:443"]

You can supply a mix of IPv4 and IPv6, we will figure everything out. If you are happy to rely on defaults, supply nothing but remembers about this possibility.

Kudos to telemt: telemt/telemt#19 Encourage everyone to check their project

This fixes #321 #317 and #283

[9seconds]

I've also found out that I can use a list of DCs returned by help.getConfig to force mtg to connect to a different set of clusters. They require their own obfuscation and supply a secret. I do not want to bloat this PR and probably do in a different PR

[codecov-commenter]

Codecov Report

❌ Patch coverage is 37.06897% with 73 lines in your changes missing coverage. Please review.
✅ Project coverage is 69.04%. Comparing base (301bde8) to head (f83ee17).

Files with missing lines	Patch %	Lines
mtglib/internal/dc/telegram.go	0.00%	49 Missing ⚠️
mtglib/proxy.go	14.28%	12 Missing ⚠️
internal/cli/run_proxy.go	0.00%	6 Missing ⚠️
mtglib/internal/dc/addr_set.go	73.33%	2 Missing and 2 partials ⚠️
internal/cli/access.go	0.00%	1 Missing ⚠️
ipblocklist/files/http.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #326      +/-   ##
==========================================
- Coverage   71.31%   69.04%   -2.27%     
==========================================
  Files          79       82       +3     
  Lines        2674     2714      +40     
==========================================
- Hits         1907     1874      -33     
- Misses        672      743      +71     
- Partials       95       97       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[axkurcom]

I've also found out that I can use a list of DCs returned by help.getConfig to force mtg to connect to a different set of clusters. They require their own obfuscation and supply a secret. I do not want to bloat this PR and probably do in a different PR

There is no information yet that DC=203 used addresses other than the only one...
telemt with a special DC log did not record calls to other such DCs...

[9seconds]

@axkurcom we'll see. Given a fact that it returns only for a logged in user, it could be that it is dependend on different factors like regions, geographical proximity and so on. CDN implies network, network implies many hosts.

[axkurcom]

CDN implies network, network implies many hosts.

Telegram dont know about anycast... after that, it is extremely difficult to find "stable dependencies"...

in fact, if MTProxy is hosted in Europe, then CDN in Finland is relatively well accessible to everyone through a proxy...

[9seconds]

True, and you are spot on about anycast. Im not sure that anycast is technically feasible for Telegram, because it implies another level of presence to advertise such IP