Refactor browser options

[ka3de]

Description of changes

This PR modifies the list of supported browser options and how they are parsed based on #856 and #857. Specifically:

• Removes support for browser options specified from JS/Goja layer when calling BrowserType.Launch and BrowserType.Connect methods. Instead some browser options will now be read from scenario browser options (see Add JS scenario options k6#3036 and Add GetScenarioOptions method to ExecutorConfig interface k6#3053) and others will be parsed from environment.
• Changes browser options parsing to read every "environment related" option from environment variables. This affects options timeout, headless, debug, args, ignoreDefaultArgs and executablePath.
• Removes support for slowMo browser option. This option will not be exposed by now until a decision is made about its "applicability" (browser vs browserContext) and its implementation (see Do not expose browser slowMo option #875).

Related: #854.
Closes #858, #874, #875.

Checklist

• Written tests for the changes
• Update k6 documentation: See Epic: Update browser options documentation for v1.0.0 k6-docs#1171.
• Generate TS definitions: Not relevant.

[ka3de]

A couple of comments about the implementation:

1. As suggested in #858, initially I tried to parse browser scenario options as soon as possible, so it could fail fast in case the setup is incorrect. Unfortunately, because these options are defined at the scenario level, they are only set at the VU context whenever an iteration starts. Therefore its parsing had to be done once we get called to one of the BrowserType exposed methods through Goja (e.g.: BrowserType.Launch and BrowserType.Connect), so similar as it was previously done.

2. The current implementation panics if the browser type option set is not chromium. It is ok for the test to fail, as this field has to be mandatory now, but it should not panic the way it does. This is because if the init process in launch and connect fails, including the options parsing, we panic from launch here and connect here. This is related also with previous issues we had related with non having panic "centralized" and we did some improvements to that in ???. I believe can be fixed by returning an error from both of these methods and then parsing it for possible "fatal" error from mapping layer and reacting accordingly. Another option is to use k6common.Throw instead of panic in the current launch and connect implementations. Because this PR is already quite long, my plan is to tackle this in a separate PR.

You can test this issue with the following script:

import { chromium } from 'k6/x/browser'

export const options = {
  scenarios: {
    ui: {
      executor: 'shared-iterations',
      options: {
        browser: {
            type: 'invalid',
        },
      },
    },
  },
};
  
export default async function() {
    const browser = chromium.launch();
    const context = browser.newContext();
    const page = context.newPage()
    
    try {
      await page.goto('https://test.k6.io/', { waitUntil: 'networkidle' })
    } finally {
      page.close();
      browser.close();
    }
}

[inancgumus]

LGTM 👍

[ankur22]

Really great work here! 👏 Thanks for the well structured PR 🙂

I left a very minor nit, but happy for you to ignore it.