Update database span name: clarify target and remove fallback

[lmolkova]

Fixes #1045

Alternative to #1061

Changes

Clarifies that target depends on the operation and if target is not available, instrumentation should not fallback to other options.

E.g. for query like SELECT * FROM (VALUES (1, 'a'), (2, 'b'), (3, 'c')) AS t (id, name) that uses anonymous table, the span name should be SELECT and not SELECT {db.namespace}.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[gregkalapos]

Nice 👍

I'd maybe add 2 things here:

• The example in the PR description with the anonymous table is very useful, I think that could be part of the spec.
• The goal here is to avoid falling back to a less useful target, (that's also part of the PR description here). So my understanding is, we are ok to omit target in edge cases. But it's not really written into the spec and this PR doesn't really says that explicitly. I think it'd be worth adding it as well.

I had this in #1061:

A given instrumentation SHOULD strive for consistency in span names.


If certain queries lack this specific attribute, the instrumentation SHOULD use `{db.operation.name}` as the span name and omit `{target}`, 
rather than falling back to the next attribute in the [`{target}`](#target-placeholder) list.

(dropped the part which is different in this PR). Do we want to maybe add that part?

[lmolkova]

@gregkalapos I updated the doc with your suggestion, lmk what you think

[gregkalapos]

@gregkalapos I updated the doc with your suggestion, lmk what you think

Thanks, lgtm.