关于合并订阅/多 Profile 支持，以及未来后处理思路的讨论

[greenhat616]

之前我们在这个 issue 中设计了草案：#1276，通过重构 Profile Item 实现了该设计的后端支持：#1663。

在当前的草案中，我们将并发获取多个订阅，并一次性展示所有订阅的更新结果：

/// 订阅多个 URL
#[tracing::instrument]
async fn subscribe_urls(
    urls: &[Url],
    options: &RemoteProfileOptions,
) -> Result<Vec<Subscription>, SubscribeError> {
    if urls.is_empty() {
        return Err(SubscribeError::ValidationFailed {
            url: "".to_string(),
            reason: "urls should not be empty".to_string(),
        });
    }
    let futures = urls.iter().map(|url| subscribe_url(url, options));
    let results = futures::future::join_all(futures).await;
    let (successes, errors): (Vec<_>, Vec<_>) = results.into_iter().partition_map(|r| match r {
        Ok(val) => itertools::Either::Left(val),
        Err(err) => itertools::Either::Right(err),
    });

    if !errors.is_empty() {
        return Err(SubscribeError::MultipleErrors(errors));
    }

    Ok(successes)
}

合并操作则以第一个 URL 为准，其余 Profiles 只采用其 Proxies 部分：

/// 合并订阅
#[tracing::instrument]
fn merge_subscription(
    subscriptions: &[Subscription],
) -> (Mapping, IndexMap<Url, SubscriptionInfo>) {
    let mut data = Mapping::new();
    let mut extra = IndexMap::new();
    for (i, sub) in subscriptions.iter().enumerate() {
        if i == 0 {
            data.extend(sub.data.clone());
        } else {
            let proxies = data.get_mut("proxies").unwrap().as_sequence_mut().unwrap();
            let sub_proxies = sub.data.get("proxies").unwrap().as_sequence().unwrap();
            proxies.extend(sub_proxies.iter().cloned());
        }
        extra.insert(sub.url.clone(), sub.info);
    }
    (data, extra)
}

在重构过程中，我们一直在思考是否对本地文件提供多文件支持，并且如何处理符号链接（#1546）。我们尝试为 Profile Item 的 file 字段扩展多文件支持，但发现效果不好。如果内置合并功能，后处理流程会过于复杂，符号链接的管理也变得麻烦，最终我们选择继续保持 file 字段为单文件支持，但我们仍然在探索其他解决方案。

我们参考了移动端，尤其是 Loon 的管理思路，认为允许选择多个 Profiles 是一个可行的方向，尽管这可能与当前的处理流程有冲突。

这是当前 1.6 版本的 Profile 处理方式：

理想的多 Profile 选中处理流程应为：

主要问题是：

• 合并 Profile 时，哪些数据需要保留，保留形式是否可配置？这是否与全局链或未来规划的 GUI 处理节点冲突？
  • SubStore 的合并逻辑是如何实现的？有哪些参考内容？
  • proxies-providers 的合并是否有必要保留？
  • 是否需要提供基于 JavaScript 或者 Lua 的脚本进行自定义合并？
• GUI 处理节点
  • 是否需要参考 Loon 的配置形式，仅提供规则和代理组配置？是否需要增加额外的小功能设置？
  • GUI 逻辑应基于 Merge 扩展，还是自定义一个列表操作源语配置？
  • 需要提供一个 Meta 信息用于自定义 filter？
• 保护字段
  • 需要明确保护字段和可接管字段的界限，如 DNS、TUN 配置。大部分用户希望完全接管字段，少部分希望保留手写配置，GUI 仅管理少数配置项。这个思路可行，但边界需要讨论。
  • 是否应该通过明确的开关关闭可接管字段的覆写，或者通过复选对话框选中不需要接管的字段？这可能对大部分用户来说过于繁琐，且不能针对单个 Profile 进行选择。

[greenhat616]

讨论中的多Profile草案已经通过 PR #1663 实现并合并进入主线。