Add section on span status for databases

[lmolkova]

Addresses the DB part of #1536.

Let's polish it for databases and then expand to other conventions (and potentially have a generic guidance).

The intention is to keep exception event part experimental since

• there doesn't seem to be a consensus or a common approach for it
• span events is going away

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.

[maryliag]

should this have any requirements about not having any confidential data? Similar to how we have on metrics errors where we don't add if it shows actual values of queries, etc

[lmolkova]

I don't see how database instrumentation can determine if there is any sensitive or confidential data in the arbitrary exception message. Someone can put sensitive data into database name (bluesky has DB per user and they might call them accordingly), but how can we provide basic observability in the common case if we assume the worst?

Happy to consider any specific cases when we can do something on the instrumentation side.

[maryliag]

Sorry if I wasn't clear, I didn't mean that is the job of the instrumentation to determine this, I meant more as a recommendation, that this sentence could include something on the lines of

SHOULD set the span status description when it has additional information about the error that aligns with [Span Status Description][SpanStatus] and does not contain sensitive data.

[lmolkova]

Suggested change

	note: Specify how to set span kind for database operations.
	note: Specify how to set span status for database operations.