Ideas for improving the group() built-in function

[na--]

It would currently be quite difficult to implement, but ideally, once #883 is resolved, we may be able to partially override some of the global options in a group() call. That way we can set different tags for all metrics emitted in that group, or set local default HTTP options once #761 is implemented (especially useful for stuff like authentication).

In a way, something like that already happens, since the group system tag's value is changed inside of the group() call, but it's not flexible or user-configurable at all.

[na--]

I've mentioned in in the linked issue (#891 (comment)), but a users's question on Slack reminded me of that idea to extend this proposal, so it can help with some use cases where users don't want specific metrics measured. Specifically, we should be able to add an option/parameter to the group() call (or something else) that basically silences all metrics that would have been emitted during the execution of the callback function. I think this should be achievable by replacing the metrics channel in the lib.State object, like how group() currently replaces the Group. Though it's an open question about the issues this approach would have when we have event loops (#882)...

[mstoykov]

Given how group does not work with async and we will likely have to figure out somethign for it's current usage and that this will likely have to do with https://github.com/tc39/proposal-async-context and/or goja#AsyncContextTracker.

I have opened #3392 where we will explore making this async compatible and hopefully more generic.