Concurrent calls to DefaultTracer results in 2 tracers existing with one being inactive

[LordRalex]

Describe the bug
When 2 goroutines run at the same time at start-up and both call the apm.DefaultTracer call, then a race-condition occurs where both calls attempt to create a new Tracer. In this scenario, one tracer loses out and disables itself while the other tracer continues to work.

I encountered this during a start-up scheduled task and creation of a gin handler. The gin tracer was being marked as inactive while the scheduled process continues.

There is a read-lock on the tracer. However, this is only when it is read, and is a very short lock. When the first caller runs, it gets null and releases the lock. While the first caller is creating the new tracer, the second caller runs this method, and passes through the lock, also seeing null. This caller then creates a new tracer. When SetDefaultTracer is called after it creates it, it will terminate the tracer that the first caller generated and made default.

To Reproduce
Steps to reproduce the behavior:
Following code:

go func() {
  web := gin.New()
  web.Use(apmgin.Middleware(web))
}

go func() {
  trans := apm.DefaultTracer().StartTransaction("gameCacheSync", "schedule")
  defer trans.End()
}

Expected behavior
Single tracker exists, which sends transactions from both Gin and scheduled process.

[axw]

Thanks for the report @LordRalex! We'll get that fixed shortly.