Improve cloud aggregation for different URLs with the same name tag

[na--]

We currently don't aggregate HTTP metrics with different url tags, but with the same name tag. While that somewhat makes sense, it's counter-intuitive and doesn't follow the logic for URL grouping: https://docs.k6.io/docs/http-requests#section-url-grouping

[cuonglm]

I tried researching and still stuck in best mechanism for url tag when name tag is the same.

Any idea @mstoykov @na-- @imiric ?

[na--]

Hmm we basically have 3 options:

1. don't emit a url tag for the aggregated metric value
2. emit a url tag that has the same values as the user-specified name tag
3. try to derive some value for the aggragated url tag, based on the values of the individual url tags

If we choose option 3, and I'm not sure that's the best one, I feel like we shouldn't over-complicate it. While there are a bunch of complex and costly algorithms for string similarity/difference, in our case I'm not sure they would be needed, since we're dealing with URLs. So, I thing that can easily derive some sensible aggregated url value by finding the longest common prefix and suffix in all of the url tags and having the resulting url tag be something like <common-prefix>{}<common-suffix>. So, if we have these URLs:

https://www.somewebsite.com/somepage?id=12&action=wat&some=thing
https://www.somewebsite.com/somepage?id=13&action=test&some=thing
https://www.somewebsite.com/somepage?id=99&some=thing

The end result should be something like https://www.somewebsite.com/somepage?id={}&some=thing... Not perfect, but should work for the vast majority of cases. @robingustafsson, @sniku, @mstoykov, @imiric, thoughts?

[na--]

We discussed this in a call and the currently favored approach is none of the three I proposed above. Instead, for now (pending verification), we can just delete the url tag from all HTTP metrics we send in the cloud output, since the name value is what we display there - name is either the same as the url, or whatever the user manually set.

So we can save some bandwidth if we don't send the url while not losing any important data and aggregating everything better. It also allows us to auto-generate something like the <common-prefix>{}<common-suffix> value for url in the future, without a second breaking change (which is not the case for 2.), if it's requested or needed.

@sniku, the only potential UX issue I see by removing the url tag is that users may try to filter by it, but that's potentially very confusing and thus a big UX issue. So I'm a bit more hesitant now if we should just delete it, but I also don't like the second approach of just overwriting it with the value of name 😕 ...

[na--]

After some more internal discussions, we're back to the option of setting url to be equal to name in the cloud output. It's not ideal, but it seems like the least bad option in terms of UX.