Clone Bundle's URLs into lib.Archive

[joanlopez]

What?

It modifies the Bundle.makeArchive function so Bundle's URLs (pointers) aren't directly reused by the lib.Archive it constructs, but cloned ("deep copy") and set.

Why?

Because the Archive.Write method normalizes and anonymizes these URLs to prevent certain details (like OS's user, HOME dir, etc) to be leaked to the GCk6, but we not always want these modifications to be propagated to the Bundle's URLs - e.g. when running the test script locally: k6 cloud ... --local-execution.

Review notes

A better explanation of why this (#4168) happens is because the process goes as follows:

1. The test is loaded and configured, which includes the initialization of the first runner, and thus the cache of the module resolutions.
2. The process of creating the test remotely also involves the creation of the archive, which modifies the URLs, as described above.
3. Later, when the test is executed, the module resolution fails because it points to a different, non-cached, import path, due to the step 2.

Note this started to fail since we introduced this change because the old way of doing the same was k6 run -o cloud, and in that case we were not sending any archive at all. Now, the archive is an opt-out "feature", enabled by default.

Also, note that another approach to fix this issue (#4168) could consist on something like "reinstantiating" the first runner, so the "new paths" are cached again, and/or to somehow make it all work with the normalized and anonymized URLs.

However, that sounded a bit counterintuitive to me, plus I suspected that may cause other issue later (like k6 errors/warning not pointing to the correct paths locally, etc).

While doing a "deep copy" of these URLs to "isolate" changes on Archives sounded good to me, because I could not think of any scenario where that could be a problem, and logically it kinda makes sense to make the Archive "standalone".

Checklist

• I have performed a self-review of my code.
• I have added tests for my changes.
• I have run linter locally (make lint) and all checks pass.
• I have run tests locally (make tests) and all tests pass.
• I have commented on my code, particularly in hard-to-understand areas.

Related PR(s)/Issue(s)

Fixes #4168

[joanlopez]

Other fields here, like this Filesystems are also passed by reference (note it's a map), and thus are likely to be modified. However, that doesn't seem to cause any issue so far.

[mstoykov]

Nice catch @joanlopez 🎉

[olegbespalov]

Looks good! Would it be possible to introduce a test case for that (maybe in separated PR)?

[oleiade]

Just passing by to send a huge kudos for fixing this @joanlopez 🚀