Story: Secure Podman API Socket with TLS/mTLS

Summary: Enable Podman API socket to securely serve connections over TCP using TLS and mutual TLS (mTLS), allowing for secure remote access without relying on SSH forwarding or external proxies.

Description: As a user migrating from Docker or operating in a secure enterprise environment, I need the Podman API socket to support TLS/mTLS for direct TCP connections. This will allow me to securely expose the Podman API across network boundaries where SSH is not permitted or desired, and where manual proxy configuration for end-users is not feasible. This feature is critical for direct integration with client applications (e.g., java-docker-client or similar tools) that expect an HTTPS-secured API endpoint. This story consolidates the request from RHEL-91221 and the detailed discussion in containers/podman#24583.

User Story:
• As a system administrator / developer, I want to configure the Podman API socket with TLS/mTLS certificates, so that I can provide secure, authenticated, and encrypted access to the Podman API over TCP without using SSH.

Acceptance Criteria:
1. API Command Extension:
○ podman system service command is extended with new flags (e.g., --tls-cert, --tls-key, --tls-ca) to specify server certificate, private key, and trusted client CA certificates for the API socket.
○ The podman system connection add command (or an equivalent for client-side configuration) is extended to allow specifying client-side TLS material (e.g., client cert, key, CA).

2. TLS Encryption:
○ When configured with server-side TLS flags, the Podman API socket successfully serves connections encrypted with TLS.
○ Standard TLS clients (e.g., curl with --cert, --key, --cacert) can successfully establish a secure connection and interact with the Podman API.

3. Mutual TLS (mTLS) Authentication:
○ When configured for mTLS (both server and client provide certificates), the Podman API socket enforces client certificate validation.
○ Connections without a valid client certificate (signed by the trusted CA specified on the server) are rejected.
○ Connections with a valid client certificate are successfully authenticated and allowed.

4. Error Handling & Feedback:
○ Invalid or missing TLS/mTLS configuration (e.g., malformed certs, non-existent paths) results in clear and actionable error messages when starting the podman system service.
○ Client connection failures due to TLS/mTLS issues provide informative diagnostic messages.

5. containers/common Configuration Integration:
Necessary fields are added or modified within github.com/containers/common configuration structures to support storing and retrieving TLS/mTLS certificate and key paths, as well as CA certificate paths, for both server and client configurations (referencing related work like containers/common#2249).
These configuration fields are properly exposed and utilized by Podman for API socket setup.

6. Documentation:
○ Official Podman documentation is updated to include clear instructions and examples for configuring and using the Podman API with TLS/mTLS for both server and client sides.

7. No Regression:
○ Existing podman system service functionality (e.g., non-TLS socket over Unix domain sockets, or unsecured TCP for local use) remains unchanged and functional.