Cross-platform SqlColumnEncryptionCertificateStoreProvider support

[edwardneal]

Wider idea: #3048.

SqlColumnEncryptionCertificateStoreProvider is the only built-in SqlColumnEncryptionKeyStoreProvider implementation which needs no significant code changes to enable cross-platform support out of the box. I've removed the Unix-specific guards on this and widened the test coverage.

In the process, I've switched the Linux/macOS tests to use SqlColumnEncryptionCertificateStoreProvider rather than the Azure Key Vault provider. This doesn't seem to have had an impact on the code coverage statistics, but it's notable nonetheless.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.71%. Comparing base (b1f7eaf) to head (bc78fae).
Report is 6 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3014      +/-   ##
==========================================
+ Coverage   72.68%   72.71%   +0.02%     
==========================================
  Files         285      284       -1     
  Lines       59155    59166      +11     
==========================================
+ Hits        42998    43023      +25     
+ Misses      16157    16143      -14     

Flag	Coverage Δ
addons	92.58% <ø> (ø)
netcore	75.45% <100.00%> (+0.06%)	⬆️
netfx	71.11% <65.38%> (-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.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[edwardneal]

This has reached the point where it needs a rough review by the SqlClient team.

We can make SqlColumnEncryptionCertificateStoreProvider work on Windows, Unix and macOS, as expected. There's one caveat to this though: Unix and macOS will only support certificates from the user store. I've proceeded with this, working from the starting point that this isn't a major barrier - a systemd unit will often run as a user and be able to access a user-level certificate store anyway. Does that caveat make this non-viable?

Secondly: around half of this PR's additions and a quarter of its file changes are because I moved the certificates which were previously static byte arrays in the code to .pfx files which are included within the test assembly as embedded resources. In the process, I also added a password to these .pfx files - macOS didn't seem to import them as certificates without one. Is this going to fall afoul of any security policies against checking private keys into the repo, or is it not a problem if they're only used for the tests?

If all's well, I'll likely cherry-pick some of the test changes included in this PR into a new one; it should clean up the diff a little and make it easier to review.

[David-Engel]

I'm pretty sure the private keys and password won't pass credential scanners. Can the files be generated on the fly with random passwords?

[edwardneal]

They can, and in some places they are - some of the tests launch a PowerShell script to do that. I'll work out a way to make this consistent across the tests...

Edit: it looks like there are three or four different sets of hardcoded certificates; some have hardcoded passwords, some don't have passwords at all. I'm working on a common approach which does as you've suggested; that'll be a separate PR for ease of review.

Second edit: I've decided to split this prerequisite into two PRs, the first of which is #3034.