Use start_as_current_span by default

[c24t]

This is a follow up to #198, which renamed start_span to start_as_current_span.

There were several examples and tests with calls to start_span that look like they should have been updated, including the example in the main README.

[c24t]

To @toumorokoshi's point in https://github.com/open-telemetry/opentelemetry-python/pull/198/files#r333820669, I think there's a good argument for using the shorter start_span the default name.

[hectorhdzg]

This package doesn't need/use current span reference, feels like start_span is actually available for this kind of scenarios

[c24t]

That's a good point, maybe we do want start_span here.

We may want to put spans into the context by default, even if we close the span before returning control. If start_span started and activated the span, and we had another method named start_span_but_dont_activate, would it still be a good idea to use the latter here?

@Oberon00 what do you think?

[toumorokoshi]

the current span is actually referenced here, abstracted in the propagators layer:

opentelemetry-python/ext/opentelemetry-ext-http-requests/src/opentelemetry/ext/http_requests/__init__.py

Line 77 in 30568de

propagators.inject(tracer, type(headers).__setitem__, headers)

https://github.com/open-telemetry/opentelemetry-python/blob/master/opentelemetry-api/src/opentelemetry/propagators/__init__.py#L47

Which I think is the correct behavior. I'm sure others will also rely on the assumption that the span was started here, regardless of whether the integration directly uses the context or not.

I would argue that most common cases require the tracer to use the new span, and we should only opt out of that behavior in advanced cases.

I'm +1 for start_span_but_dont_activate, or maybe pass that it as a keyword argument. (will_activate=False).

[Oberon00]

I think this is either a misusage of the inject API or the inject API should provide a way to supply the Span to propagate.

But I definitely agree on using start_as_current_span here. E.g. consider what should happen if we decided to represent HTTP redirects as their own spans: They would need to become child spans.

[Oberon00]

In general, I view the active span more as an inter-instrumentation communication. If only a single instrumentation library was involved it could devise its own mechanism to manage parent spans easily (although ofc relying on the current span should still be preferred for parent/child relations).

[toumorokoshi]

Nice catch! I just noticed this a couple days ago, as it's causing a few of the tests in the tracecontext suite to fail (since spans are created but not activated, so the same span is used over and over again).

This PR is needed to unblock:
#228