重构 `GM_xmlhttpRequest` 的实作

[cyfung1031]

    if (param1.responseType === "stream" || param1.fetch || param1.redirect) {
      // 只有fetch支持ReadableStream、redirect这些，直接使用fetch
      return this.CAT_fetch(param1, sender, resultParam);
    }

不正确。 GM_xmlhttpRequest 用 fetch API 模拟 xmlhttpRequest 的条件是， fetch:true, redirect, anonymous
另外 GM_xmlhttpRequest 呼叫 CAT_xxxx 这个写法也不合适

xmlhttpRequest版 和 fetch版 的实作部份应该放在 pkg 工具库
而不是跟 GM_API 代码混在一起
（ dealXhrResponse 和 dealFetch 等相关代码）
实际应用时，xmlhttpRequest版 的 xmlhttprequest 由Offscreen 提供

3. stream, buffer, redirect, responseType 等部份要重写

4. 严格使用 xmlhttpRequest ，只有在 fetch: true 才使用 fetch版。重申 fetch 只是一个较好的做法，但 GM_xmlhttpRequest 本身所有options都可以用 最原始的 xmlhttpRequest 实现 （不包括TM增加的 redirect 和 anonymous）

---

由于MV3倾向fetch API
因此，实作部份，应把logic倒过来， fetch 预设true, 除非 onProgress 那些xhr限定的东西指定了

---

補充

stream 要 fetch. 因為xhr response 要等 readyState4

chrome 只能在同一頁面的service worker 傳 blob/arraybuffer, chrome mv2/mv3 的 messaging api 是 JSON serialization 而不是 firefox的 structured clone algorithm.

• https://developer.chrome.com/blog/workers-arraybuffer?hl=en
• https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Transferable_objects
• https://developer.chrome.com/docs/extensions/develop/concepts/messaging?hl=en#serialization
• https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Chrome_incompatibilities#data_cloning_algorithm

日後chrome 或會改成 structured clone algorithm

• https://issues.chromium.org/issues/40321352

@types/chrome 說明有錯

• Wrong Description for chrome.declarativeNetRequest.RuleCondition.tabIds DefinitelyTyped/DefinitelyTyped#73946

[CodFrm]

不正确。 GM_xmlhttpRequest 用 fetch API 模拟 xmlhttpRequest 的条件是， fetch:true, redirect, anonymous

anonymous？ responseType === "stream"也需要 fetch API 的，anonymous不需要

这块代码实现可以重构一下，确实有点糟糕

严格使用 xmlhttpRequest ，只有在 fetch: true 才使用 fetch版

严格使用xmlhttpRequest会造成兼容性问题，需要根据option自动切换fetch的

---

不要 fetch 预设为true，这个API的就是以 XMLHttpRequst 为目标设计的，脚本也是按照 XMLHttpRequst 使用的，这么修改会造成兼容性问题

[CodFrm]

刚刚看到了 #847 (comment) ，看起来 responseType === "stream" 可以使用 xmlhttpRequest ，不过 anonymous，为什么也要用fetch，不太明白，看起来是TM的设定

[cyfung1031]

不过 anonymous，为什么也要用fetch，不太明白，看起来是TM的设定

xhr 的withCredentials 预设 false. true 时传cookies （same-origin & cross-origin)
false 时 same-origin 传cookies, cross-origin 不传.

fetch api 的 anonymous true 时， same-origin & cross-origin 都不传 cookie

[CodFrm]

不过 anonymous，为什么也要用fetch，不太明白，看起来是TM的设定

xhr 的withCredentials 预设 false. true 时传cookies （same-origin & cross-origin) false 时 same-origin 传cookies, cross-origin 不传.

fetch api 的 anonymous true 时， same-origin & cross-origin 都不传 cookie

原来如此，不过我之前直接用unsafe header的方式处理掉了

[cyfung1031]

• 为什么 GM_xmlhttpRequest 在连接 @connect 以外的网域下，是弹出询问用户批准，而不是跟TM一样返回error? #884

• 要加一个选项，预设TM行为拒绝@connect以外网域。选项变更时，会跟从旧SC做 @connect 以外的许可确认(烦人设计）

• 使用 OPFS 进行 service_worker 和 offscreen 的blob资料传递

• 不接受連接至 Blacklist Domain 'Refused to connect to "https://example.org/": URL is blacklisted'

[CodFrm]

使用 OPFS 进行 service_worker 和 offscreen 的blob资料传递

这里为什么要使用 OPFS 来操作？现在的方式也没问题呀

[cyfung1031]

使用 OPFS 进行 service_worker 和 offscreen 的blob资料传递

这里为什么要使用 OPFS 来操作？现在的方式也没问题呀

背景脚本用 GMxhr的话，传Blob很麻烦。service_worker本身不支持 URL.createObjectURL. 用 OPFS 是最有效做巨大资料传送

[CodFrm]

使用 OPFS 进行 service_worker 和 offscreen 的blob资料传递

这里为什么要使用 OPFS 来操作？现在的方式也没问题呀

背景脚本用 GMxhr的话，传Blob很麻烦。service_worker本身不支持 URL.createObjectURL. 用 OPFS 是最有效做巨大资料传送

后台脚本是运行在 offscreen-sandbox 中的，可以使用 URL.createObjectURL，OPFS 应该是持久化的存储