Contribute additional semantic conventions to OpenTracing

With OpenTracing, span tags and loggings keys are completely free-form. Rather than try to set limitations, they have used conventions to try to standardize on names for common tags. OpenTracing has a few already defined here: https://github.com/opentracing/specification/blob/master/semantic_conventions.md

For example: db.instance and db.statement, so you know the host and query that was used.

These conventions are extremely helpful to us:

• Some of these conventions could be utilized to help us correlate data between Jaeger, Prometheus, and structured logs. For example a host field across all three, could be helpful in troubleshooting a problematic node. A common session_id could help us map a users logs to their traces.
• There are also some conventions that could relate to other areas of GitLab, like the environment in use or the particular line of code a span is representing.
• We don't plan to write our own tracers, which means we cannot directly control this.

Because of their importance, we should contribute additional semantic conventions to do two things:

1. Increase adoption of these tags being used
2. Establish a convention so that everyone in the tracing community can benefit, and better interoperate

Suggested Additional Semantic Conventions

Tag Name	Type	Notes and examples
Environment	string	The name of the environment the span is originating from. For example, production or staging. Could also be used to differentiate between blue/green deploys.
Version	string	The software version that is generating this span. This could be used to detect canaries versus GA versions.
Source File / Line #	array	Trace back to where the span is being generated in the source code. filename.rb:232, filename2.rb:214
Commit SHA / Tag	string	If available, specify the version or SHA of the built code in order to find the proper line.
Session ID	string	The ID of a particular session