[Feature Request] Reverse the order of proxies to improve efficiency

[developerforeverowo]

It isn't possible to detect the problem in simple and short tests!!!
To understand how much necessary this feature is, you need to use free proxies (which have a short life time) in a daily basis without removing the older ones when they die, to have a too long list.
The users mostly are affected by this problem but they are mostly unaware of how it affects them.
Users of Telegram Desktop and Cherrygram have reported much better performance when using free proxies.

The order of checking, showing and switching proxies should be like TDesktop, Cherrygram, iOS, Telegram X and so on... i.e. for the in-memory list, the ascending order is a bad choice. The list should be saved in reversed order on the disk. (look at SharedConfig.java)

The problem:
Free proxies have a short life time, so the user constantly adds new proxies and the list becomes too long. The latest added proxy (which is too old so dead) stays forever at index 0 at the beginning of the in-memory list (I didn't mean the in-UI list). The latest added proxies which are fresh and available, are added at the end of the in-memory list so they get checked lastly in proxy switch algorithm, each time the currently connected proxy dies. By doing this, there's less chance to quickly find an available proxy at the beginning of the list because the first proxies are older. With this sort, too much time is needed to reach the end of the list and find an available proxy each time.
In addition, on restarts, the order of the in-UI proxy list (which is not always as same as the in-memory list order) gets reset (and becomes the same as it) and the green and available proxies get shown at the bottom of the in-UI list (where is impossible for the user to scroll to, in a too long list). The ping sort service won't move them up, until it test their ping. It takes too much time because it tests latest proxies lastly.
The worst part is, that to overcome this problem, some users remove red and unavailable proxies frequently (i.e. doing proxy management manually!!!) and this solution causes two problems:

1. Healthy and available proxies can't always pass the ping test successfully so they may sometimes get unavailable or red, by mistake. So the user always removes healthy and working proxies mistakenly and replaces them again and again. An infinite loop. A time killing and useless effort!
2. The proxy list stays always short, so user always risks lockups because all list items may become unavailable at once when the list is short.

The in-memory sort is correct (time descending) In Telegram Desktop, Cherrygram, etc so there's no problem when the list is long, because the latest added proxies (which are probably healthy and working) are always accessible at the top of the in-UI list in these clients and earlier proxies get shifted down each new one gets added. A long list becomes problematic only when the order is wrongly reversed, e.g. in Monet.

It's much easier to get online with Telegram Desktop despite not having ping sort, auto switch and other proxy features which Monet has.

The solution:
The latest added proxies are luckier to be working because earlier added proxies are older, so they are usually dead or blocked by ISPs. So the proxy rotation controller should start checking proxies from the latest proxy instead of the earlier proxies which have less chance to be available, to skip checking a lot of old proxies and find the available proxy in less time (Fixing SharedConfig.java is enough, so no need to touch ProxyRotationController.java). Also, the user prefers to see latest added proxies viewed at the beginning of the list after restarts, when the order gets reset temporarily. Because scrolling to the end to see the proxies added a moment ago, is hard when it's long. Also, ping checks and ping sort should get started from the latest one, not the earliest. There's a big chance for old proxies to be unavailable when the list is too long.
The current in-memory list order should become time descending, affecting all these algorithms.