Add support for typed spans via a typed span builder

[danielkhan]

Spans represent different canonical types of operations.
Examples are

• Local operations like method invocations
• HTTP requests (inbound and outbound)
• Database requests
• Generic RPC requests like GRPC

A span consists of a number of mandatory and optional attributes that add information about the represented operation to it.

Depending on the canonical type of an operation some attributes might be needed to represent and analyze a span correctly.

Example: A HTTP request needs a status code to distinguish successful or unsuccessful operations.

Right now, spans can be created freely and it’s up to the implementor to set all the attributes needed to represent the given type.

Proposal

• Implement a TypedSpanBuilder for all platforms that ensures that all needed attributes and the type is set.
• Add a field CanonicalType that contains the type of span.

I've created a document to help to specify this new feature.

[danielkhan]

As discussed in our last meeting, I've created a POC for this feature.

Implementation

I've created a separate project with a dependency on opencensus-node.
There I've extended Span as TypedSpan to accept a type attribute that has the type CanonicalType
I've created an Interface HTTPClientTypedSpan that contains methods specific to HTTP Client spans.
The type definitions can be found here.

The implementation of HTTPClientSpan sets the type and the kind properties and will proxy all the dedicated methods to addAttribute.

Additionally I've added a property mandatoryAttributes and extended the end() method to check if all mandatory attributes are set.
This is optional - more of an idea I'd like to discuss. Maybe it's too rigid.

How to integrate in OC

We were first discussing a builder pattern but as we see on the HTTP sensor we don't have access to the Span class but use a factory-like method to create it.
So we would need to add startHTTPClientRootSpan, startHTTPClientChildSpan which seems too intrusive.

Alternatively, I'd propose to extend TraceOptions with a field type and then decide in startRootSpan and startChildSpan which class to create.