Catch tarn timeout errors and throw with more contextual information

[stevendarby]

As discussed in the comments of #1764.

Sometimes we will get the error:

Error: operation timed out for an unknown reason
at /azp/_work/1/X/node_modules/tarn/dist/PendingOperation.js:17:27
at runNextTicks (node:internal/process/task_queues:60:5)
at listOnTimeout (node:internal/timers:545:9)
at process.processTimers (node:internal/timers:519:7)

It's not immediately obvious that this relates to sql at all and the stack isn't much help. Only through googling etc. can you establish it's likely coming from mssql's use of tarn.

One definite trigger for this error is when the pool size has reached the limit, all connections are borrowed, and it has to wait for a connection to become available. After 30 seconds of waiting, this is thrown. (The exact time may be configurable but this is the default).

Feature request: if mssql could catch this and throw an error with more contextual information, this would be quite useful and save time investigating. For example, in the scenario above, the message could make it clearer that it timed out waiting for a connection to become available. This would prompt a developer to check their pool size, check for queries that are taking too long etc.

Crucially, the scenario above is just the one I know about. There could be other scenarios that this error is thrown in, and mssql could catch and rethrow with the appropriate information for those too, in order to steer the developer's investigation and fix in the right direction. There are 5 other issues in this repo that mention operation timed out for an unknown reason and several stack overflow posts on it, so it's something others have been confused about before.

FWIW: We use mssql for tests, where all queries are sequential and awaited- never running in parallel. Locally, we always see that when starting a query there is only ever at most 1 connection in the pool, which is always available. However, sometimes running in cloud pipelines, we get this error. It doesn't seem possible that it's because the pool is exhausted, but with limited info we're currently steering our investigation that way and adding extra logging to monitor pool health and so on. If the error contained more information, we might spend less time investigating.

Thanks!