Warn users on unsupported parts of setup returned data

[mstoykov]

Feature Description

Currently setup can return whatever and it will be send to default and teardown.

A lot of users are confused what actually happens because for the most part it works perfectly and as long as you:

1. don't put unsupported types in the data
2. don't expect that edititng it will be observable between VUs and stages

you can 100% think that it is just that exact same object.

But it isn't - it is a copy made by marshalling and then unmarshalling from JSON. This definitely makes it so

1. If you have added a function it will be nil ... which is very confusing. Doubly so if it's a method on a class and the instance of that class is still there.
2. You try to edit it and expect that teardown will see the changes.

Both of those are kind of documented, but I would expect that a lot of people wouldn't find them.

Suggested Solution (optional)

Write some, hopefully not very complicated code, to go through the whole object and check for known problems such as functions and print a warning about it.

We can probably try to write the name of the property or even the "path" to it as that will improve the message a lot.

For the second one we have discussed it a lot in #2043, but I wonder if we can just freeze that object after it's unmarshalled 🤷

Already existing or connected issues / PRs (optional)

#2043

[Aksh-Bansal-dev]

I would like to work on this issue. I'm new to the codebase but with some help, I will be able to make a PR.

[Aksh-Bansal-dev]

Currently, we get this error if we return a function as setupData.

Should we print some different error/warning in this case(functions as return value)?

[na--]

This is the place of the code where we marshal the data returned from setup():

k6/js/runner.go

Line 289 in 3305656

r.setupData, err = json.Marshal(v.Export())

Feel free to try and implement this feature, just keep in mind that it's not as simple as it might look like. You'd need to be familiar with the Go and JS type systems and also might need to read up on some Goja internals (https://pkg.go.dev/github.com/dop251/goja)). We will also need a ton of tests here, to know that we are not making any breaking changes.

[harishsambasivam]

@na-- I would like to pick up this issue. I'm new to the codebase, will read through goja and write a change proposal before staring the work!

[harishsambasivam]

Connected to #2808

[na--]

Sounds good, thanks! 👍