Perf: add allocation free path for close notifications

[Wraith2]

When a real (not CancellationToken.None) cancellation token is used in an async query a callback is registered against it to make sure that the pending async action can be cancelled correctly. To do this two pieces of information are needed in a continuation and there is only one state parameter so a closure or state object have to be used, unless...

Since we own the task that is being passed into the continuation and in all current cases we are not providing a task state object and we're directly using TaskCompletionSources we can set the TCS state object that is passed to the child to be one of the bits of state that we need and then we can use the state parameter as the other. This is a little tortuous but I've annotated it in the code so it's clear why it's being done. I've also left the original allocating pathway in place so if anyone ever needs that state parameter they can revert and the code will still work just with an extra allocation per invocation.

This saves one tuple allocation per async call when a real cancellation token is used.

[Wraith2]

@David-Engel can i get this reviewed and merged please. It's been open 2 years now and it's really not a large or complex change.

[codecov]

Codecov Report

Patch coverage: 100.00% and project coverage change: +0.40 🎉

Comparison is base (a5ad838) 70.59% compared to head (6286277) 70.99%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1198      +/-   ##
==========================================
+ Coverage   70.59%   70.99%   +0.40%     
==========================================
  Files         306      306              
  Lines       61667    64083    +2416     
==========================================
+ Hits        43533    45495    +1962     
- Misses      18134    18588     +454     

Flag	Coverage Δ
addons	92.88% <ø> (ø)
netcore	73.71% <100.00%> (+0.31%)	⬆️
netfx	69.58% <100.00%> (+0.44%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...netcore/src/Microsoft/Data/SqlClient/SqlCommand.cs	84.37% <100.00%> (+0.78%)	⬆️
...core/src/Microsoft/Data/SqlClient/SqlConnection.cs	79.23% <100.00%> (+0.01%)	⬆️
.../netfx/src/Microsoft/Data/SqlClient/SqlBulkCopy.cs	70.41% <100.00%> (-0.05%)	⬇️
...t/netfx/src/Microsoft/Data/SqlClient/SqlCommand.cs	74.17% <100.00%> (+0.34%)	⬆️
...etfx/src/Microsoft/Data/SqlClient/SqlConnection.cs	60.18% <100.00%> (+0.76%)	⬆️

... and 12 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[David-Engel]

The only remaining "failures" in the checks are from Windows+.net7, which I disabled in the CI pipeline to eliminate 33 jobs and improve code coverage merge time. The matrix was getting huge. I left .net7 coverage for Linux/macOS since the matrix there isn't so big. The failures were originally from the "Enable TCP, NP & Firewall" task, which is fixed now.

[DavoudEshtehari]

Might be irrelevant to this change, but why only ExecuteScalarAsync doesn't have a RegisterForConnectionCloseNotification method call?

[Wraith2]

No idea. It might be that scalar is just ExecuteReader wearing a silly hat so the call to close notification may be lower in the call hierarchy.

[Kaur-Parminder]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).