Add http.asyncRequest

[mstoykov]

Feature Description

With the addition of event loop months ago, k6 did get the ability to have asynchronous operations, like all the other js tools ;).

While we have added some experimental APIs and will likely add more that use this there is a small problem.

Using asynchronous APIs in combination with synchronous ones that take long time will block the event loop. Which will prevent the asynchronous calls from completing.

export default () => {
  const ws = new WebSocket(url);
  ws.addEventListener("message", (e) => {
    console.log(e);
  });
  http.get(url2);
  http.get(url3);
  // more http requests
  http.get(url10);
}

This will effectively not log a single message until all the http requests are finished. This might take a few minutes. If the websocket was supposed to return something back there is a very good chance the server would've timeouted this connection.

In order for this to not be the case we need asynchronous http call.

While getting the new-http API will be best this is unlikely to happen soon so a stop gap solution seems like a good middle ground.

Suggested Solution (optional)

Implement asyncRequest with the same signature as request but instead of returning the response directly, it will return a Promise that will be resolved with the response or rejected with an error in the same cases as http.request would do it.

No other changes are at this point proposed including:

1. changes to any of the arguments - as that will likely be more confusing
2. no http.asyncGet, http.asyncPost and friends. While they might be slightly easier to write, there are already confusion about which have bodies and which not and arguably are saving very small amount of writing.
3. no http.asyncBatch - given that http.batch is mostly used to do multiple requests at the same time it seems less useful to have this in the case that you can just make a bunch of asyncRequests and Promise.all on them for example.

The above might change, although the hope is that this will reduce the maintenance burden, while still giving enough functionality to users until the new http API lands.

Already existing or connected issues / PRs (optional)

No response