Bumps [go.k6.io/k6](https://github.com/grafana/k6) from 0.53.1-0.20240925100229-86ab6e3ceee8 to 0.54.0.
- [Release notes](https://github.com/grafana/k6/releases)
- [Commits](https://github.com/grafana/k6/commits/v0.54.0)

---
updated-dependencies:
- dependency-name: go.k6.io/k6
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>

This fix ensures that the taskqueue is closed when the iteration ends.
If the taskqueue isn't closed when the iteration ends the k6 process
will hang indefinitely. We used to rely on page.close, but now that the
life cycle of the iteration is controlled by the VU we can safely rely
on the VU context to ensure that the taskqueue is closed (if it isn't
already closed).

`Description` should be `description`

This will allow us to write the test for all platforms that either work
with Control or Meta when performing keyboard actions. E.g.
Control+click on windows, and meta+click on mac to open a link in a new
window.

The test now doesn't test with combo keys which doesn't work yet.
Instead we're using dblClick.

The sobek code has been moved to the mapping layer, leaving the main
business logic sobek free for keyboard.press.

The sobek code has been moved to the mapping layer, leaving the main
business logic sobek free for keyboard.type.

This is to enable us to still work with the sync keyboard APIs with the
Sobek changes removed from the business logic side of keyboard.

waitForSelector may result in a confusing error message:

        selector did not resolve to any element

We're now explaining which selector didn't resolve to an element.

page.on only worked with console message, but we will need it to work
for metric messages too. This change allows us to send any type and
perform the type check in the handler.

It will need to be used in the page mapping.

Using switch to allow for multiple events.

This is what the user will receive in the page.on callback for the
metric event. It's just a skeleton for now.

We can now map and return the metric back to the user so that they can
work with it in the handle.

We want to use the regex engine in the sobek runtime which should be
the same or similar to other JS regex engines. This function will be
used to work with the user defined regex to group metrics with url
tags.

The callback is what will be used to work with the sobek runtime. We
want to avoid using sobek outside the mapping layer.

The name needs to be sent back to the caller that needs it. It is done
via a channel.

When running things on the taskqueue, they are done async. We need to
make this process synchronous. We're relying on the nameCh (the same
channel that the name is sent to the caller on) to notify the called
when the handler has complete.

This function will call the handlers one by one, allowing each handler
to check the url matches and return the name. Each handler will
overwrite the name if multiple handlers match with the given url. This
function needs to wait for the handler to complete before proceeding to
the next handler.

Co-authored-by: İnanç Gümüş <inanc.gumus@grafana.com>

This makes working with an atomic int more maintainable.

Instead of working with goroutines and channels to propagate the name
back from GroupURLTag, a name field is updated in ExportedMetric. The
call to the taskqueue is synchronised so when the handler is called we
can safely wait for it to complete instead of relying on channels and
contexts to wait for it to complete.

This better represents what is happening. When a match is found, the
metric is tagged. It is not grouping anything, the grouping is a wanted
side effect.

We're now only creating a single MetricEvent for all handlers.

Leaving the names as in the go code.

From some of my testing it would seem that PostDataEntries doesn't
contain more than a single entry. I've tried with various types of
request data such as:
- application/json
- multipart/related
- application/x-www-form-urlencoded
- application/form-data

and so far none of them exhibits a change in behaviour where more than
one element in PostDataEntries is occupied.

We can work with the 0th entry of PostDataEntries for now until a need
arises for needing to work with the rest of the slice (i.e. we have a
better idea of when that happens).

Mapped methods are lowercase so that we can test them. They're also used
in JavaScript like so.

So that we can use it the mapping test.

JavaScript functions are conventionally lowercase, and since we changed
Tag to tag from the Go side, we should also rename this script.

So that we can get rid of the non-conforming metric mapper. This way, we
don't have to deal with error handling in other mappers in the test.
This provides a uniform way.

Also, this is a prior step for the generalization of the page on API.

Co-authored-by: Ankur <ankur.agarwal@grafana.com>

This type contains `page.on` events. Rather than using `any` to describe
any event, we use a named type to make it explicit what we're using.
Also, this will eliminate type assertions from the code, making it type
safe.

We now use a type-safe way to describe and pass events throughout the
code. We get rid of type assertions. This provides a way to extend the
type later on with new page on event types.

This will be used by all page on event names. With this, we won't
require whether a provided event is valid. The compiler will enforce it
for us.

This is safe to do so as we will no longer pass a rogue string to this
method. Only the page on event names can be passed to this function.

Unless, of course, somebody converts a string with an incorrect name to
PageOnEventName to call this function. This will easily be catched in
reviews, and nobody would do such a thing. We follow the Go idiom of
being pragmatic instead of being highly defensive. Also, this method is
used by the mapping layer, and there is already an event name check.

The page on mapping is large and hard to work with while making the
changes. Putting it into a new function is subjetively more readable and
makes it easier to work with the function.

No need to specify the implementation details that can change. Our main
goal here is to map the page on event handler to sobek.

We're uniforming the events.