Define the fallback tracer name for invalid values.

[carlosalberto]

Fixes #1472

Keeps the original invalid value (to be handled by the backends instead), while asking implementations to log this as an error.

[arminru]

Please add a changelog entry. Thanks!

[bogdandrutu]

Personally I would prefer to use "" as a fallback and treat that as invalid value. That way we are consistent with our protocol as well.

[yurishkuro]

I think it's worth comparing this with a missing service name, which is quite bad and we already have some fallback value for it. A missing/blank instrumentation library feels very much meh, i.e. a blank string would do just fine as a fallback with very little downside.

[carlosalberto]

I think it's worth comparing this with a missing service name

Indeed, I had considered this as well, and was wondering whether we should try to go with "unknown_name" or a similar one, to be in line with that a missing service name ends up doing ;)

[Oberon00]

The now says that a missing service name is not an error (just an unknown service name), while a missing instrumentation name is an API usage error. Note that a missing service name naturally appears by doing nothing in particular while you have to decide to pass an empty string or null to GetTracer to get an invalid instrumentation name.

[Oberon00]

Suggested change

	"`<INVALID INSTRUMENTATION NAME PROVIDED>`" literal, in order to signal that the
	string `<INVALID INSTRUMENTATION NAME PROVIDED>`, in order to signal that the

[arminru]

@carlosalberto Please add a changelog entry that this fallback is now specified for SDK implementations.

[bogdandrutu]

@Oberon00 @carlosalberto can you please document why empty string is not good? When it comes to receiving empty string from a source what does that mean?

I would vote for empty string since it means less unnecessary bytes on the wire and this case has to be treated by the receiver anyway.

[carlosalberto]

From the discussion today: we want to allow the user passing null or empty strings, as this is something that can/should be handled by the backend (as backends must very likely already handle the null value case), while logging (even if only once) about the invalid name value.

[carlosalberto]

@open-telemetry/specs-approvers Please re-review ;)

[SergeyKanzhelev]

@carlosalberto pls resolve couple suggestions from @yurishkuro before merging. Thank you!