Deprecate tlsconfig.SystemCertPool

[thaJeztah]

The wrapper originally existed for historical compatibility reasons that no longer apply:

• 55aadc3 removed the pre-Go-1.7 fallback implementation, leaving the wrapper mainly as a shim around x509.SystemCertPool.
• 3723764 kept a Windows-specific exception because x509.SystemCertPool on Windows was not yet reliable at the time.
• f652133 and 21876c5 preserved that behavior while the package continued to support older Go versions and older Windows handling.

With current Go versions, x509.SystemCertPool is the correct API on all supported platforms, including Windows, and the old special-case is no longer needed. Keeping a package-local wrapper only adds indirection and retains stale historical behavior and comments.

This change keeps the existing behavior of using the system trust store as the base when building non-exclusive root pools; it only deprecates the local wrapper in favor of the standard library entrypoint.

- Description for the changelog

tlsconfig: Deprecate `SystemCertPool`, which is now an alias for [`x509.SystemCertPool`](https://pkg.go.dev/crypto/x509#SystemCertPool) in stdlib.

- A picture of a cute animal (not mandatory but encouraged)

[Copilot]

Pull request overview

This PR deprecates the package-local tlsconfig.SystemCertPool wrapper and switches internal call sites to use the Go standard library’s x509.SystemCertPool directly, removing historical Windows-specific behavior.

Changes:

• Update TLS pool construction to call x509.SystemCertPool() directly.
• Adjust tests to use x509.SystemCertPool() and fail hard if unavailable.
• Deprecate tlsconfig.SystemCertPool as a thin passthrough to x509.SystemCertPool.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
tlsconfig/config.go	Switch certPool() to call x509.SystemCertPool() directly.
tlsconfig/config_test.go	Update tests to use x509.SystemCertPool() and treat errors as fatal.
tlsconfig/certpool.go	Deprecate SystemCertPool() wrapper and simplify implementation.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[thaJeztah]

FWIW; looks like containerd also has a fallback, but without trying the system-pool first; I'm guessing this was done for the same reason (but it skips the "if it fails" check);

On Linux it uses the system-pool;
https://github.com/containerd/containerd/blob/6b7e237fc7f68602b362c89edd0038c7b22a3922/remotes/docker/config/config_unix.go#L40-L42

On Windows it always returns an empty pool;
https://github.com/containerd/containerd/blob/6b7e237fc7f68602b362c89edd0038c7b22a3922/remotes/docker/config/config_windows.go#L39-L41

I think that was for the same reason, unless they explicitly want to always exclude the system-pool on Windows. I'll look at a PR in containerd to open that discussion.

https://github.com/containerd/containerd/blob/49c9f303b1d35101bb798cb37c57b06cd1eacf5e/remotes/docker/config/hosts.go#L190-L207

[thaJeztah]

For this repo (go-connections), the change is effectively a no-op on current Go versions; the if err != nil would only happen in catastrophic cases on current Go versions, but effectively always use the system-pool, not the fallback.