fix: handle timeouts during tls negotiation for strict encryption

[MichaelSun90]

Network socket not correctly cleaned up when connection timeout fires during TDS8.0 TLS negotiation #1558

[codecov]

Codecov Report

Merging #1564 (33ab74b) into master (4f3e210) will increase coverage by 0.21%.
The diff coverage is 95.65%.

@@            Coverage Diff             @@
##           master    #1564      +/-   ##
==========================================
+ Coverage   80.45%   80.67%   +0.21%     
==========================================
  Files          92       92              
  Lines        4692     4709      +17     
  Branches      871      871              
==========================================
+ Hits         3775     3799      +24     
+ Misses        644      633      -11     
- Partials      273      277       +4     

Files Changed	Coverage Δ
src/connection.ts	65.97% <95.65%> (+1.23%)	⬆️

[MichaelSun90]

@arthurschreiber remove the TDS 7_1 checks against SQL server 2022 since 7_1 suppose not work with SQL server 2022 and it did failing the encrypt tests. We did no run into this because the added encrypt tests are not actually running due to a error within our test. If we still want to keep the 7_1 test run against SQL server 2022 for certain reason, we can also add some logic to skip the tests like that we did in 'should reset Connection'.

[MichaelSun90]

Figured out, that signal.reason can be undefined which causing an additional error if we do tostring and compare it with the error that has been caught see if it include the abort title. However, just err === signal.reason still does not handles the case that :
signal.reason :

Error: AbortError
    at AbortController.abort (C:\Users\msun\Documents\GitHub\tedious\node_modules\node-abort-controller\index.js:56:31)
    at Timeout._onTimeout (C:\Users\msun\Documents\GitHub\tedious\src\/connection.ts:2116:18)
    at listOnTimeout (node:internal/timers:569:17)
    at processTimers (node:internal/timers:512:7)

err is:

AbortError: The operation was aborted
    at EventEmitter.onAbort (C:\Users\msun\Documents\GitHub\tedious\src\/connector.ts:108:18)
    at EventEmitter.emit (node:events:514:28)
    at AbortSignal.dispatchEvent (C:\Users\msun\Documents\GitHub\tedious\node_modules\node-abort-controller\index.js:28:23)
    at AbortController.abort (C:\Users\msun\Documents\GitHub\tedious\node_modules\node-abort-controller\index.js:58:17)
    at Timeout._onTimeout (C:\Users\msun\Documents\GitHub\tedious\src\/connection.ts:2116:18)
    at listOnTimeout (node:internal/timers:569:17)
    at processTimers (node:internal/timers:512:7) {
  code: 'ABORT_ERR'
}

if (err === signal.reason || err.name === 'AbortError'){
    return;
}

if(signal.reason && signal.reason.tostring().include('AbortError')) {
     return;
}

both of these will handle the errors correctly, but not exactly a clean solution in my opinion.
Not sure if we should go with either one or @arthurschreiber you have suggestions for handling this.

[arthurschreiber]

@MichaelSun90 I changed the code to check for signal.aborted instead, and I think this now has the correct behaviour.

If the signal (which is coming from the connectTimeout) was aborted, that means that the connect timeout has fired and we need to ignore that error (because a different error will be generated by the connect timeout code.

Anyway, hopefully this can be cleaned up via the changes in #1562.

[github-actions]

🎉 This PR is included in version 16.4.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[MichaelSun90]

@MichaelSun90 I changed the code to check for signal.aborted instead, and I think this now has the correct behaviour.

If the signal (which is coming from the connectTimeout) was aborted, that means that the connect timeout has fired and we need to ignore that error (because a different error will be generated by the connect timeout code.

Anyway, hopefully this can be cleaned up via the changes in #1562.

Thanks for help on this change, and release it ! 🙇‍♂️