Fix | Don't validate server certificate when using Authentication option but not encrypting

[David-Engel]

When using the authentication option (Authentication=SqlPassword or other value), the netfx code would try to validate the server certificate regardless of whether or not encryption was negotiated. This resulted in the requirement to set TrustServerCertificate=true, even if client and server encryption was off, in order for connections to succeed when the server doesn't have a public certificate provisioned. This also manifests in the same manner when using Authentication=ActiveDirectoryIntegrated. In a Kerberos flow, that option behaves like IntegratedSecurty=true.

[codecov]

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (4f73355) 68.46% compared to head (33928a4) 72.36%.
Report is 3 commits behind head on main.

Files	Patch %	Lines
...nt/netfx/src/Microsoft/Data/SqlClient/TdsParser.cs	80.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2224      +/-   ##
==========================================
+ Coverage   68.46%   72.36%   +3.90%     
==========================================
  Files         309      309              
  Lines       62181    62196      +15     
==========================================
+ Hits        42570    45008    +2438     
+ Misses      19611    17188    -2423     

Flag	Coverage Δ
addons	92.88% <ø> (ø)
netcore	76.51% <ø> (+10.44%)	⬆️
netfx	69.85% <80.00%> (-0.02%)	⬇️

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Matteo-T]

Looks reasonably good to me :)

[DavoudEshtehari]

Could we have a unit test to cover this case if already there isn't one?

[David-Engel]

Could we have a unit test to cover this case if already there isn't one?

The test ADIntegratedUsingSSPI (renamed in this PR from the inaccurate ADInteractiveUsingSSPI) was exercising this bad path in our Kerberos pipelines but the old ones are configured with TrustServerCertificate=true to avoid this issue. The new Kerberos pipeline wasn't using TrustServerCertificate=true, so it was hitting this issue.

I added another test to specifically / force Authentication=SqlPassword and TrustServerCertificate=false to help ensure this doesn't regress in localhost pipelines.