Improve the communication for automatic extension resolution

[codebien]

What & Why?

1. Now that automatic extension resolution is the default doesn't make sense to repeat it for each logline, this should be obvious as it is the default.
2. The current waiting time on a blinking prompt is not optimal to me, it doesn't seem obvious to me if I should wait or the program got stuck so I clarified this aspect in the message.

Checklist

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

Checklist: Documentation (only for k6 maintainers and if relevant)

Please do not merge this PR until the following items are filled out.

• I have added the correct milestone and labels to the PR.
• I have updated the release notes: link
• I have updated or added an issue to the k6-documentation: grafana/k6-docs#NUMBER if applicable
• I have updated or added an issue to the TypeScript definitions: grafana/k6-DefinitelyTyped#NUMBER if applicable

Related PR(s)/Issue(s)

[joanlopez]

Nit;

Suggested change

	Info("Provisioning a custom binary as the current doesn't satisfy all dependencies," +
	Info("Provisioning a custom binary because the current one doesn't satisfy all the dependencies," +

I think it's slightly more precise and clear

[joanlopez]

Overall, I'm wondering whether we should use either extensions or dependencies, and if we should be consistent with that use in the two messages modified in this PR.

[mstoykov]

Some thoughts:

1. I do think we should use extensions instead of dependancies as the secodn can and likely will be misunderstood as ./somelib.js Or even worse something else that needs to be download such as chromium or a c library or whatever
2. I do not like the wordign of "Provisioning" - we will be downloading a binary. I think we should jsut use download instead of the internal term.
3. "custom binary" also makes it seems like we will make this specifically for the user, but it isn't.

I have made proposal below

[mstoykov]

I guess after the discussion now nad looking more closely at some of the code:

1. we do not always download, sometimes we use a local copy
2. we do not log anything in the above cases at any log level

I do reall think it will be nice to one differntiate between those two case and potentially list both the binary link and potentially the binary path on the fs. Maybe not at Info but debug level

[codebien]

Overall, I'm wondering whether we should use either extensions or dependencies

I guess the word dependencies here has been used because there is k6 itself to be resolved which is not an extensions.

I will look deeper into a better proposal.

[codebien]

I do not like the wordign of "Provisioning"

@mstoykov same for provisioning. I guess it used to collect the two operations (build + download).

[mstoykov]

Suggested change

	Info("Provisioning a custom binary as the current doesn't satisfy all dependencies," +
	" may take a few seconds as it needs to download the new one.")
	Info("Downloading a binary as the current isn't build with all required extensions," +
	" may take a few seconds.")

The current listing of deps also IMO needs help.

[mstoykov]

Some thoughts:

1. I do think we should use extensions instead of dependancies as the secodn can and likely will be misunderstood as ./somelib.js Or even worse something else that needs to be download such as chromium or a c library or whatever
2. I do not like the wordign of "Provisioning" - we will be downloading a binary. I think we should jsut use download instead of the internal term.
3. "custom binary" also makes it seems like we will make this specifically for the user, but it isn't.

I have made proposal below

[mstoykov]

Suggested change

	WithField("deps", deps).
	WithField("extensions", deps).