Implement the File API's openSync method as a temporary helper/workaround for await operations in the init context

[oleiade]

As part of #3141, implementing the agreed-upon design for k6's File API, we intend to implement a temporary openSync function for the File API module.

Why

Using asynchronous code or the await keyword in the init context is currently impossible. For instance, the following is not valid within a k6 script and will throw an error:

await someAsyncFunc()

export default async function () {
    // ...
}

We anticipate this capability will sooner or later land in k6, with the ESM (#2258) support. But in the meantime, that would make it harder for users to effectively use the open function in the init context.

What

As a result, we intend to implement the openSync as a synchronous counterpart to the async open function #3142, to allow users to open files in the init context. As pointed out by @mstoykov, there is an existing workaround in Javascript, and we should probably have the function implementation use that workaround under the hood.

/*
 * openSync opens a file and returns an instance of a
 * `File`.
 */
openSync(path: string): File

⚠ Disclaimer

We expect this method to be removed when we support asynchronous code in the init context. Therefore, we should clearly, and consistently document that this method is a convenience for users and is expected to be deprecated in the future.

[oleiade]

We have decided in the Pull Request that proposed an implementation for this method to not introduce it. At least, yet.

We want to avoid introducing an API we knew we would deprecate, especially in an experimental module.

We consider the initial problem this was trying to solve (providing a good developer experience to cater to the lack of await in the init stage) valid until await is supported in the init stage. Further, I propose that we do not make the fs module a stable one, unless the syntax is supported in the init stage and allows const file = await open() there 🙇🏻