[Feature Request] Graceful handling of failed external resources — skip unavailable subscriptions instead of failing entire import

[julxxy]

Problem

When a configuration file references multiple external subscription URLs
(e.g., in [Proxy Group] or managed config), Surfboard currently treats
the entire import as failed if any single URL returns a non-200 response
(e.g., 403, 404, or timeout).

Real-world scenario

Some airport providers design their subscription endpoints to be
single-use only — the link returns a valid response on the first request,
but returns 403 on subsequent requests (by design, as an anti-leeching measure).

With 10 subscription URLs in a config, if just 1 of them returns 403,
Surfboard marks the other 9 (which are perfectly valid) as unavailable
and the entire config import fails.

Expected Behavior

Surfboard should adopt a best-effort / fault-tolerant strategy:

• Fetch all external resources concurrently
• Skip any URL that returns a non-2xx response or times out
• Import the config using only the successfully fetched resources
• Optionally: show a warning indicating which URLs were skipped and why

This is similar to how Promise.allSettled() works vs Promise.all() —
partial failure should not block the whole operation.

Current Behavior

Any single failed URL causes the entire config import to fail with no
partial recovery.

Impact

• Users with configs referencing 10+ airport subscriptions are completely
  blocked from importing if even one provider uses a restrictive API design
• There is no way to work around this on the user side without manually
  removing the failing URL from the config before importing

Suggested Fix

When fetching external resources during config import or update:

1. Use parallel fetching with individual error isolation
2. Filter out failed responses (non-2xx / timeout)
3. Proceed with available resources
4. Surface a non-blocking warning to the user about skipped URLs

Related: #300 (subscription timeout logic)

Environment

• Surfboard version: latest
• Platform: Android

[getsurfboard]

If a rule points to an empty proxy group, how should the traffic be handled? DIRECT or REJECT?

[julxxy]

If a rule points to an empty proxy group, how should the traffic be handled? DIRECT or REJECT?

// buildEmptyConfig 按客户端类型返回最小合法空配置，避免客户端解析报错
func buildEmptyConfig(reason, client string) []byte {
	ts := time.Now().Format("2006/01/02 15:04:05")
	switch client {
	case "surge":
		return []byte(fmt.Sprintf(`# sub-proxy fallback
# Reason: %s
# Generated_at: %s
[General]

[Proxy]
⚠️ 订阅拉取失败，请检查原始订阅链接是否有效 = ss, 9.9.9.9, 9500, encrypt-method=aes-128-gcm, password=123456

[Proxy Group]

[Rule]
FINAL,DIRECT
`, reason, ts))
	case "shadowrocket":
		return []byte(fmt.Sprintf(`# sub-proxy fallback
# Reason: %s
# Generated_at: %s
[General]

[Proxy]
⚠️ 订阅拉取失败，请检查原始订阅链接是否有效 = ss, 9.9.9.9, 9500, encrypt-method=aes-128-gcm, password=123456

[Proxy Group]
proxy = select,DIRECT

[Rule]
FINAL,DIRECT
`, reason, ts))
	default: // clash
		return []byte(fmt.Sprintf(`# sub-proxy fallback
# Reason: %s
# Generated_at: %s

proxies:
  - {name: "⚠️ 订阅拉取失败，请检查原始订阅链接是否有效", type: ss, server: 9.9.9.9, port: 9500, cipher: aes-128-gcm, password: 123456, udp: false}

proxy-groups: []

rules:
  - MATCH,DIRECT
`, reason, ts))
	}
}