Support skipping TLS certificate/hostname verification for S3 snapshot storage (private CA / self-signed endpoints)

[dragonclaw-dragonflydb]

Is your feature request related to a problem? Please describe.

Dragonfly's S3 snapshot storage (--s3_endpoint, used for SAVE/snapshot upload+load to S3-compatible backends) always performs strict TLS certificate verification with no way to disable it. This is implemented in helio/util/http/http_client.cc, TlsClient::CreateSslContext():

SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, VerifyCallback);

There's no flag or environment variable to relax this. The only way to avoid a certificate verify failed error today is --s3_use_https=false, which drops TLS entirely (plaintext HTTP) rather than just skipping verification — not an acceptable tradeoff for traffic carrying AWS SigV4-signed credentials.

This is a real blocker for anyone running Dragonfly against internal/private S3-compatible object stores (e.g. NetApp StorageGrid, MinIO, Ceph RGW) that use a private/self-signed CA not present in the container's OS trust store. Rebuilding images or using init containers to inject a custom CA bundle into the system trust store works, but is operationally heavier than it needs to be, and other tools in the same observability/data pipeline space already support this out of the box.

For example, Vector supports this directly for its aws_s3 sink:

send_to_s3:
  type: aws_s3
  endpoint: https://internal-storagegrid-endpoint
  region: "us-east-1"
  tls:
    verify_hostname: false
    verify_certificate: false

Describe the solution you'd prefer

Add flags to control S3 TLS certificate/hostname verification independently, keeping HTTPS enabled (encryption in transit preserved, just skipping trust validation):

• --s3_tls_verify_certificate (default: true) — when false, skip CA chain verification (SSL_VERIFY_NONE instead of SSL_VERIFY_PEER)
• --s3_tls_verify_hostname (default: true) — when false, skip hostname/SNI matching against the cert

This mirrors Vector's naming/semantics, which should feel familiar to anyone already managing a mixed observability pipeline including both tools.

Implementation-wise, this would need to thread through from server_family.cc (flag definitions) → AwsS3SnapshotStorage constructor (src/server/detail/snapshot_storage.cc) → TlsClient::CreateSslContext() (helio/util/http/http_client.cc), likely by parameterizing the verify mode passed to SSL_CTX_set_verify instead of hardcoding SSL_VERIFY_PEER.

Describe alternatives you've considered

• --s3_use_https=false — works, but disables TLS entirely (plaintext transport), which is not acceptable when the traffic is on a network you don't fully control, or when compliance requires encryption in transit even if cert validation is relaxed.
• Injecting the private CA into the container's OS trust store (update-ca-certificates via init container or custom image build) — works today, but adds operational overhead to every deployment against a private-CA S3 endpoint, and doesn't fit well with the dragonfly-operator's standard pod template for users who don't control the base image.

Additional context

Confirmed by reading the current TLS context setup in helio/util/http/http_client.cc::TlsClient::CreateSslContext() — verification is unconditionally SSL_VERIFY_PEER with no override path, and there's no CA-bundle injection flag for the S3 client either (s3_use_helio_client path uses OS default cert locations only, no custom CA file/dir option).

This would primarily help teams running Dragonfly for snapshot storage against internal S3-compatible endpoints with private CAs (StorageGrid, MinIO, Ceph RGW, etc.) in air-gapped or private-network deployments.