kvserver: don't fork Raft application spans on followers

Raft application was forking a span on followers, instead of the more
usual creation of child spans. This was done probably because the parent
span is usually a long-running Raft worker span, and adding children to
such long-running spans is generally not a great idea. But these days
there are better ways of dealing with long-running tasks - they can have
Sterile spans, meaning that the parent declares that it doesn't want any
children. And indeed the task in question uses such a Sterile span:
https://github.com/cockroachdb/cockroach/blob/2ad2bee257e78970ce2c457ddd6996099ed6727a/pkg/kv/kvserver/scheduler.go#L217

So, the forking is not needed and this patch changes it to a regular
child relationship.

This has a couple of benefits:
- the parent was not always a long-running taks. I believe it can also
  be a snapshot application, in which case we want the span in question
  to be a regular child (e.g. because tracing a snapshot application
  should also include this span). This shows that the decision about
  what kind if relationship a child should have to its parent is not
  appropriate to be taken by the child.
- less contention on the active spans registry. Forking a span
  internally creates a "local root" span that needs to be added to the
  registry directly, instead of being added indirectly through its
  parent.

Release note: None

Author: andreimatei

pkg/kv/kvserver/replica_application_decoder.go

@@ -159,7 +159,7 @@ func (d *replicaDecoder) createTracingSpans(ctx context.Context) {
 				)
 			}
 		} else {
-			cmd.ctx, cmd.sp = tracing.ForkSpan(ctx, opName)
+			cmd.ctx, cmd.sp = tracing.ChildSpan(ctx, opName)
 		}
 	}
 }