remove service.name -> g.co/gae/app/module mapping from trace exporter's default mapping

[dashpole]

Fixes #711

The UI now supports service.name.

This brings the go trace exporter in-line with trace exporters in other languages.

[codecov]

Codecov Report

Merging #715 (373d737) into main (e0f6140) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #715   +/-   ##
=======================================
  Coverage   69.66%   69.67%           
=======================================
  Files          42       42           
  Lines        4840     4838    -2     
=======================================
- Hits         3372     3371    -1     
- Misses       1317     1318    +1     
+ Partials      151      149    -2     

Files Changed	Coverage Δ
exporter/trace/trace_proto.go	64.70% <ø> (-0.30%)	⬇️

... and 2 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[aabmass]

Is there any concern of this being a breaking change?

[dashpole]

We expect users to prefer service.name, and don't expect many to be using g.co/gae/app/module.

[AndreasBergmeier6176]

This actually IS a breaking change since g.co/gae/app/module still, at least until January 26th 2024, gets mapped to Service filter.
It would be ok, if the Service filter in GCP Trace would also filter service.name, but it does not!
Thus EVERY developer now needs to get taught to manually search by entering service.name because there is also no hinting for that name in the UI.
Maybe in the future it would be better to sync with the UI team to either improve UX or at least not to break it.

[dashpole]

@AndreasBergmeier6176 sorry about that! I've raised it with the UI team, and will report back here when it is fixed. We did work with the UI team on this, but missed the issue you've encountered. Please let me know if you find any other discrepancies caused by this change.

[dashpole]

@AndreasBergmeier6176 the UI team got back to me, and it isn't an easy problem to fix because of limitations on the trace query language. They said it will likely be fixed as part of broader changes planned for later this year.

In the meantime, you can revert back to the previous behavior with:

trace.New(
	trace.WithAttributeMapping(func(k attribute.Key) attribute.Key {
		switch k {
		case "http.path":
			return "/http/path"
		case "http.host":
			return "/http/host"
		case "http.method":
			return "/http/method"
		case "http.user_agent":
			return "/http/user_agent"
		case "http.status_code":
			return "/http/status_code"
		case "service.name":
			return "g.co/gae/app/module"
		}
		return k
	})
)

Again, very sorry about that.