[feature request] built in DNS over HTTPS for resolving Shadowsocks server's domain name, configuration of DNS retry strategy

[LindaFerum]

Is your feature request related to a problem? Please describe.
A more private and flexible way to resolve server's domain name, complete with a solution to minor "server roaming" woes (e.g. when running servers on Oracle Cloud without a permanently assigned IP.

When server reboots, it gets new IP.

With this feature, upon detecting connection failure (or when first setting up connection for that matter) the Shadowsocks android client will explicitly use DNS over HTTPS to try and get new server's IP, redoing resolution on every attempt.

Server updating its DNS records (and using DNS with low TTL, such as Cloudflare) is up to server to do properly.

Describe the solution you'd like

Add following options

Use built in DNS-over-HTTPS
(checkbox)

DNS-over-HTTPS resolvers
(field with comma-separated list of DNS-over-HTTPS resolvers, for example:
@https://cloudflare-dns.com/dns-query,@https://mozilla.cloudflare-dns.com/dns-query,@https://dns.quad9.net/dns-query )

The resolvers are tried in order, e.g. if cloudflare fails, then restart connection and retry using mozilla, if that fails restart and resolve using quad, if that fails try cloudflare again and so until you get the fresh server IP

retry resolution on connection attempt
(checkbox)
if connection breaks/fails, always try getting fresh server IP using DNS-over-HTTPS
If unchecked will keep "banging" old IP until phone reboot / app restart (just to add more flexibility)

Maybe also add a more explicit way to specify connection attempt time out (e.g. 60 seconds, if server not responding then restart connection, retry resolution as per (2) and (3) )

Describe alternatives you've considered
Using android's builtin DNS-over-HTTPS
Using a local DNS solution

Much harder to configure, have less flexibility, as far as I understand android can not try multiple DNS-over-HTTPS resolvers in case one gets blocked

Additional context
solves the problem of servers with not-stable IPs (which incidentally work really well in countries that tend to block known "suspected VPN endpoints by IP)

Unlike normal DNS resolution also prevents local observer from gaining useful information

Provides low-downtime solution to "minor" cases of server roaming (your downtime is basically "time for server restart + time for DNS record update by the server + DNS TTL" give or take a few seconds)