misc: Replace @packages/extension methods that are now implemented by WebDriver BiDi when BiDi is enabled

[AtofStryker]

What would you like?

I would like to replace the most possible amount of web extension apis handled by @packages/extension in Firefox with the WebDriver Bidi automation client(s) created in #30220

Why is this needed?

Over time, the use of an unsigned web extension is likely going to be removed from Firefox (see bugzilla thread). With the introduction of BiDi, Cypress can now leverage the methods introduced in the specification to replace much of the use of the web extension.

Other

This should replace most of the methods (in red) outlined in the State of Automation spreadsheet except the downloads browser API methods (possibly).

[AtofStryker]

This has been spiked into in BIDI_AUTOMATION_CLIENT_EXTENSION, which cuts over the methods possible in the web extension (cookies, screenshots, resetting between specs, etc) all on commit 7f2c012. Most the failures I can see are related to resourceType being missing, but right now there is too much noise in the CI run to see the failure gap between this commit and the base #30220. The firefox driver tests look to be hanging, so there might be some bugs on this commit, but otherwise system tests do not have a lot of failures and it looks like it will be in a good spot to develop once resourceType is supported. It is also worth noting that we cannot eliminate the web extension completely because browsingContext.downloadWillBegin is not supported yet (or at least webdriver errors when I try to subscribe to this event stating it doesn't exist) and no method for listening on download status is available, i.e. no equivalent to CDP's Page.downloadProgress, which we would need to remove the download behavior from the extension. We also need the extension for tab styling, etc, but this is outside the realm of automation.

[AtofStryker]

Now that BiDi support is released in Cypress #30870, I revisited this in #31209, which is based on top of #31200. It looks like we have mostly what we need to cut this over, which can be seen in 82b6dbe which has a nearly passing build except one test (will elaborate below). This gets us 90% off of the web extension, but we still need to use:

• browser.downloads.onChanged to determine when a download is cancelled or changed. It looks like this might be fulfilled in webdriver-bidi should let users know when a download is completed w3c/webdriver-bidi#427
• browser.cookies.onChanged which is tracked to be added to BiDi in Add a "storage.cookieChanged" event w3c/webdriver-bidi#830

As mentioned above, we have a nearly passing build. The one test that is failing here is the browser_reset_spec system test. This has to do with reset:browser:state in the BiDi automation client not having a way to clear the storage data like we do in the web extension. We need similar methods like CDP has, such as Storage.clearDataForOrigin and Network.clearBrowserCache. To get around this, I based 8f73f05 on top of 82b6dbe which proxies the method to the web extension to clear the storage data as a workaround. This workaround gets us to a passing build. Ideally, we can replace this once w3c/webdriver-bidi#798 is complete.

We should be able to release these changes in Cypress 15 to get us much closer to full BiDi support within Firefox, with less reliance on the web extension for general automation.