fix(mysql): add enhancedDatabaseReporting to mysql

[haddasbronfman]

Which problem is this PR solving?

fixes #1237

Short description of the changes

I added a config object to MySQLInstrumentation with a field called dbStatementSerializer. This is a function which the user can set and decide how to parse his db.statement.

[codecov]

Codecov Report

Merging #1337 (75d0fab) into main (1ee197e) will decrease coverage by 0.19%.
The diff coverage is 96.55%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1337      +/-   ##
==========================================
- Coverage   96.08%   95.89%   -0.20%     
==========================================
  Files          14       18       +4     
  Lines         893     1168     +275     
  Branches      191      232      +41     
==========================================
+ Hits          858     1120     +262     
- Misses         35       48      +13     

Impacted Files	Coverage Δ
...metry-instrumentation-mysql/src/instrumentation.ts	93.18% <94.11%> (ø)
...emetry-instrumentation-mysql/src/AttributeNames.ts	100.00% <100.00%> (ø)
...e/opentelemetry-instrumentation-mysql/src/utils.ts	100.00% <100.00%> (ø)
...tapackages/auto-instrumentations-node/src/utils.ts	98.21% <0.00%> (ø)

[blumamir]

Thanks @haddasbronfman , Maybe I am missing something, but wouldn't all the potentially sensitive values still be written to the db.statement by default?

[haddasbronfman]

You're right.
(This is why I thought to add the dbStatementSerializer in the first place).
But what can we do now?
Serializer is not an option because we should discuss it at the SIG, and enhancedDatabaseReporting is also not an option because it makes no sense to capture the values when they already appear in the db.statement.

[blumamir]

You're right. (This is why I thought to add the dbStatementSerializer in the first place). But what can we do now? Serializer is not an option because we should discuss it at the SIG, and enhancedDatabaseReporting is also not an option because it makes no sense to capture the values when they already appear in the db.statement.

The instrumentation actually receives the plain SQL statement without values, and it inject the values here by calling the format function:

  if (typeof query === 'string') {
    return values ? format(query, values) : query;
  } else {
    // According to https://github.com/mysqljs/mysql#performing-queries
    // The values argument will override the values in the option object.
    return values || query.values
      ? format(query.sql, values || query.values)
      : query.sql;
  }

This transforms a query such as SELECT * FROM users WHERE password = ? into SELECT * FROM users WHERE password = "secret".

I think that if we remove the format, we can record the query directly into the values attribute as desired without capturing sensitive data.