Improve span name for the SQL SET statement to the AutoSqlSanitizer

[markallanson]

Is your feature request related to a problem? Please describe.
Not related to a problem

Describe the solution you'd like
The current AutoSqlSantizer implementation does not provide a useful span name for SQL SET statements. The only thing in the span in the DB name, not indication what SQL statement is executed until you drill into the details.

Describe alternatives you've considered
No alternatives considered.

Additional context
We use SET statements independently for configuring Yugabyte and Postgres Row Level Security, but the spans don't have a meaningful name in our observability tooling since there's no special case name sanitizer for this statement.

The implementation of AutoSqlSantizer needs to be updated to have special case handling for SET statements.

[breedx-splk]

Can you provide a few examples of statements that you're passing and what you think the span name should be? Please keep in mind that it should be in keeping with the database specification.

The span name SHOULD be set to a low cardinality value representing the statement executed on the database.
 It MAY be a stored procedure name (without arguments), DB statement without variable arguments, operation 
name, etc. Since SQL statements may have very high cardinality even without arguments, SQL spans SHOULD
 be named the following way, unless the statement is known to be of low cardinality: `<db.operation> <db.name>.
<db.sql.table>`, provided that db.operation and db.sql.table are available. If db.sql.table is not available due to its 
semantics, the span SHOULD be named `<db.operation> <db.name>`. It is not recommended to attempt any 
client-side parsing of `db.statement` just to get these properties, they should only be used if the library being 
instrumented already provides them. When it's otherwise impossible to get any meaningful span name, 
`db.name` or the tech-specific database name MAY be used.

• Yugabyte SET feference
• Postgresql SET reference

[markallanson]

Hi @breedx-splk - thanks for taking the time to ask for clarification.

Here's an example:

SET SESSION scope_identifier=<identifier>
SET SESSION scope_identifier=<identifier>

The names of variables are generally low cardinality (though of course it is possible for there to be some outlying cases where that statement is not true) so my personal preference would be to have a span name along the lines of

SET LOCAL scope_identifier
SET SESSION scope_identifier

I am not sure how the database name would fit into the span name. If we determined that the name of the variable would be too high a cardinality then simply:

<database-name> SET SESSION
<database-name> SET LOCAL

Would be better than what we have right now.

[markallanson]

I just realised that there's another use for SET SESSION where a variable is not being set - a statement such as:

SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL READ COMMITTED

I think it may be enough to condense such cases into SET SESSION or maybe SET SESSION CHARACTERISTICS