Bug #119559 util.dumpInstance ignores custom CA for S3/HTTPS (CURLcode 60), even though CA is in secret

Description:
In the Oracle MySQL Operator backup pod, mysqlsh util.dumpInstance fails when writing to an S3-compatible HTTPS endpoint with a custom CA. The S3 Secret includes ca.crt and is mounted to /mysqlsh/.aws; even
  with AWS_CA_BUNDLE=/mysqlsh/.aws/ca.crt, mysqlsh exits with SSL certificate problem: unable to get local issuer certificate (CURLcode = 60). 

In the same container, curl https://<endpoint> works using the same CA from the Secret.
Operator code path: mysqloperator/controller/backup_main.py calls shell.connect(backup_source) without ssl-ca/ssl-mode; storage_api.py only mounts the S3 Secret to /mysqlsh/.aws (no system trust path). MySQL Shell seems to ignore the provided CA for S3 HTTPS.

How to repeat:
  1. Run the MySQL Operator backup container (as in upstream operator commit 3b14f90).
  2. Provide an S3 Secret with accessKey, secretKey, config, and ca.crt; mount to /mysqlsh/.aws/. Optionally set AWS_CA_BUNDLE=/mysqlsh/.aws/ca.crt.
  3. Trigger a backup via operator flow (or manually): mysqlsh connects to cluster and runs util.dumpInstance with S3 options (endpoint uses the custom CA).
  4. Observe failure: RuntimeError: SSL certificate problem: unable to get local issuer certificate (CURLcode = 60).
  5. In the same container, curl https://<endpoint> succeeds using /mysqlsh/.aws/ca.crt.
  6. If you additionally mount ca.crt onto /etc/ssl/certs/ca-certificates.crt (or /etc/pki/tls/certs/ca-bundle.crt), the backup succeeds—showing mysqlsh/libcurl is not picking up the CA from AWS_CA_BUNDLE/~/.aws/ca.crt.

Suggested fix:
- Ensure mysqlsh respects AWS_CA_BUNDLE and/or ~/.aws/ca.crt for S3 HTTPS in util.dumpInstance (libcurl CA handling).
  - Alternatively, extend the operator to pass sslCa/sslMode to shell.connect or to the S3 client used by util.dumpInstance.
  - Current workaround: mount ca.crt from the S3 Secret to system trust paths so libcurl finds it.