[Feature] Implement HTTP 304 Caching w/ Rule Set and Subscription

[SukkaW]

verify

• 我已经仔细阅读项目文档，确认现有功能无法解决我的需求
• 我已经检索过现有issue，确认与现有issue的内容并不重复
• 我已经尝试自行解决，确认自己没有能力解决

功能描述

As the maintainer of the SukkaW/Surge, I maintain the ruleset.skk.moe to deliver the rule sets.

It turns out that the ruleset.skk.moe served more than 187.25 GiB data over the past 30 days, among them clients with source User-Agent containing subconverter received 46.9 GiB data, accounting for 25.04% of all the traffic.

可能的解决方案

By storing the ETag response header, it is possible to include the request header "If-None-Match" with the previously stored ETag value in future requets. If the remote returns a 304 HTTP status code, the download could be skipped and the previous cache can be re-used.

Currently, GitHub RAW, jsDelivr, and ruleset.skk.moe all return the ETag response header. By implementing support for these HTTP headers, Stash could efficiently check for updates and only download changes, significantly benefiting both rule maintainers and users by reducing both ends' bandwidth usage.

Other popular applications in this space, such as Surge, Stash, Clash.Meta (Mihomo), Shadowrocket, and Surfboard have already adopted this approach.