feature(client-encrypt): enable peer verification for stress commands

[dimakr]

Peer verification is now enabled by default for cassandra-stress, scylla-bench, and latte stress tools when client encryption is configured in Scylla. This ensures enhanced security by verifying if peer certificate is signed by the trusted CA and that the hostname/IP of the peer matches SAN specified in the peer's certificate.

Closes: https://github.com/scylladb/qa-tasks/issues/1728

Testing

• 🟢 PR-provision-test with server+client encryption enabled, covers c-s and s-b stress commands
• 🟢 artifacts ubuntu test (regression check for non-longevity test, which in the past was affected by changes in certs management logic)
• 🟢 manager sanity test (regression check for non-longevity test, which in the past was affected by changes in certs management logic)

PR pre-checks (self review)

• I added the relevant backport labels
• I didn't leave commented-out/debugging code

Reminders

• Add New configuration option and document them (in sdcm/sct_config.py)
• Add unit tests to cover my changes (under unit-test/ folder)
• Update the Readme/doc folder relevant to this change (if needed)

[fruch]

I think at least one test should enabled it (maybe some from tier1, or upgrades)

[dimakr]

I think at least one test should enabled it (maybe some from tier1, or upgrades)

peer_encryption setting is enabled by default in test_default.yaml. So it will be enabled when client_encrypt is ON.
And the client_encrypt is already enabled out-of-box in these test configs:

❯ grep 'client_encrypt: true' -ir ./
./test-cases/artifacts/ubuntu2004-fips.yaml:client_encrypt: true
./test-cases/longevity/longevity-lwt-24h-multidc.yaml:client_encrypt: true
./test-cases/longevity/longevity-50GB-3days-authorization-and-tls-ssl.yaml:client_encrypt: true
./test-cases/longevity/longevity-aws-custom-d2-workload1-3dcs.yaml:client_encrypt: true
./test-cases/longevity/longevity-1TB-5days-authorization-and-tls-ssl.yaml:client_encrypt: true
./test-cases/longevity/longevity-150GB-12h-autorization-LimitedMonkey.yaml:client_encrypt: true
./test-cases/longevity/longevity-2TB-48h-authorization-and-tls-ssl-1dis-2nondis-nemesis.yaml:client_encrypt: true
./test-cases/longevity/longevity-100gb-4h.yaml:client_encrypt: true
./test-cases/longevity/longevity-alternator-200GB-48h.yaml:client_encrypt: true
./test-cases/longevity/longevity-200GB-48h-verifier-LimitedMonkey-tls.yaml:client_encrypt: true
./test-cases/longevity/longevity-1TB-3days-authorization-and-tls-ssl.yaml:client_encrypt: true
./test-cases/longevity/longevity-encryption-at-rest-50GB-1day-authorization-and-tls-ssl.yaml:client_encrypt: true
./test-cases/longevity/longevity-aws-custom-d2-workload1-5dcs.yaml:client_encrypt: true
./test-cases/longevity/longevity-5TB-1day.yaml:client_encrypt: true
./test-cases/nemesis/longevity-5gb-1h-EndOfQuotaNemesis.yaml:client_encrypt: true
./configurations/longevity-fips-and-encryptions.yaml:client_encrypt: true
./configurations/nemesis/longevity-5gb-1h-nemesis.yaml:client_encrypt: true
...

At least some of them are used in tier1, e.g.:
jenkins-pipelines/oss/tier1/longevity-1tb-5days-azure.jenkinsfile: test_config: 'test-cases/longevity/longevity-1TB-5days-authorization-and-tls-ssl.yaml'
jenkins-pipelines/oss/tier1/longevity-50gb-3days.jenkinsfile: test_config: '''["test-cases/longevity/longevity-50GB-3days-authorization-and-tls-ssl.yaml", "configurations/network_config/two_interfaces.yaml", "configurations/advanced-rpc-compression.yaml"]'''
etc.
@fruch

[fruch]

LGTM

[fruch]

I think at least one test should enabled it (maybe some from tier1, or upgrades)

peer_encryption setting is enabled by default in test_default.yaml. So it will be enabled when client_encrypt is ON.
And the client_encrypt is already enabled out-of-box in these test configs:

❯ grep 'client_encrypt: true' -ir ./
./test-cases/artifacts/ubuntu2004-fips.yaml:client_encrypt: true
./test-cases/longevity/longevity-lwt-24h-multidc.yaml:client_encrypt: true
./test-cases/longevity/longevity-50GB-3days-authorization-and-tls-ssl.yaml:client_encrypt: true
./test-cases/longevity/longevity-aws-custom-d2-workload1-3dcs.yaml:client_encrypt: true
./test-cases/longevity/longevity-1TB-5days-authorization-and-tls-ssl.yaml:client_encrypt: true
./test-cases/longevity/longevity-150GB-12h-autorization-LimitedMonkey.yaml:client_encrypt: true
./test-cases/longevity/longevity-2TB-48h-authorization-and-tls-ssl-1dis-2nondis-nemesis.yaml:client_encrypt: true
./test-cases/longevity/longevity-100gb-4h.yaml:client_encrypt: true
./test-cases/longevity/longevity-alternator-200GB-48h.yaml:client_encrypt: true
./test-cases/longevity/longevity-200GB-48h-verifier-LimitedMonkey-tls.yaml:client_encrypt: true
./test-cases/longevity/longevity-1TB-3days-authorization-and-tls-ssl.yaml:client_encrypt: true
./test-cases/longevity/longevity-encryption-at-rest-50GB-1day-authorization-and-tls-ssl.yaml:client_encrypt: true
./test-cases/longevity/longevity-aws-custom-d2-workload1-5dcs.yaml:client_encrypt: true
./test-cases/longevity/longevity-5TB-1day.yaml:client_encrypt: true
./test-cases/nemesis/longevity-5gb-1h-EndOfQuotaNemesis.yaml:client_encrypt: true
./configurations/longevity-fips-and-encryptions.yaml:client_encrypt: true
./configurations/nemesis/longevity-5gb-1h-nemesis.yaml:client_encrypt: true
...

At least some of them are used in tier1, e.g.:
jenkins-pipelines/oss/tier1/longevity-1tb-5days-azure.jenkinsfile: test_config: 'test-cases/longevity/longevity-1TB-5days-authorization-and-tls-ssl.yaml'
jenkins-pipelines/oss/tier1/longevity-50gb-3days.jenkinsfile: test_config: '''["test-cases/longevity/longevity-50GB-3days-authorization-and-tls-ssl.yaml", "configurations/network_config/two_interfaces.yaml", "configurations/advanced-rpc-compression.yaml"]'''
etc.
@fruch

So used to be doing it the way around, so I didn't notice you did it by default