feat(tedious): context propagation to SQL Server

[mhennoch]

Calls set context_info before methods that actually execute user's SQL(omitting prepare and execBulkLoad). Relevant specification. This is opt in as it causes an extra round trip per request. .NET PR for the same thing

[github-actions]

This package does not have an assigned component owner and is considered unmaintained. As such this package is in feature-freeze and this PR will be closed with 14 days unless a new owner or a sponsor (a member of @open-telemetry/javascript-approvers) for the feature is found. It is the responsibility of the author to find a sponsor for this feature.
Are you familiar with this package? Consider becoming a component owner.

[trentm]

The previous code and this code path will return the return value of the originalMethod() call, which is typically what is wanted when wrapping. The _injectContextInfo() code path below this will not. I gather that won't matter for this instrumentation because, at least currently, every patched method's return type is void.

[trentm]

Separate question on the async behaviour here:

• Without calling set context_info, a patched conn.execSql() will synchronously call the original execSql method before returning.
• With the changes here and when set context_info is enabled, that is no longer true. Now, the original execSql will be called sometime later.

If I have JS code that does something like:

conn.execSql(sql1)
conn.execBulkLoad(sql2)

isn't there a sequencing problem here? I don't know tedious internals at all (e.g. whether and how it is queuing things). But with the example above, is it possible that the actual sequence of SQL executed is the following?

1. set context_info
2. sql2
3. sql1

[mhennoch]

This throws an error in Tedious. Docs say: Only one request at a time may be executed on a connection. Once a Request has been initiated (with callProcedure, execSql, or execSqlBatch), another should not be initiated until the Request's completion callback is called.