MLE-30237 fix serverStartStop to prevent OS command injection

[RitaChen609]

Key Security Fixes:
CWE-480 (Use of Incorrect Operator): Broken != "start" reference checks replaced with .equals("start") value checks

CWE-78 (OS Command Injection): Mitigated through:
Hostname validation [A-Za-z0-9._-]+ before any process launch
Command value validation (only "start" and "stop" allowed)
ProcessBuilder with fixed argument array instead of shell string concatenation

Test Results
New test class: ServerStartStopSecurityTest.java
All 4 security unit tests executed and passed.

[Copilot]

Pull request overview

This PR hardens the functional test failover helpers (WBFailover/QBFailover) against OS command injection when starting/stopping MarkLogic on cluster hosts, and adds unit tests to verify input validation occurs before any process launch.

Changes:

• Replace incorrect string comparisons with equals-based command validation and restrict commands to start|stop.
• Mitigate command injection by validating the hostname format and using ProcessBuilder instead of shell concatenation.
• Add ServerStartStopSecurityTest to ensure invalid hostnames/commands are rejected before any process is started.

Reviewed changes

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

File	Description
marklogic-client-api-functionaltests/src/test/java/com/marklogic/client/datamovement/functionaltests/WBFailover.java	Adds hostname/command validation and swaps Runtime.exec(sh -c ...) for a ProcessBuilder-based starter that can be overridden in tests.
marklogic-client-api-functionaltests/src/test/java/com/marklogic/client/datamovement/functionaltests/QBFailover.java	Mirrors the WBFailover hardening changes for the query batcher failover tests.
marklogic-client-api-functionaltests/src/test/java/com/marklogic/client/datamovement/functionaltests/ServerStartStopSecurityTest.java	Adds tests to verify validation happens before any process creation attempt.

[rjrudin]

These two tests haven't actually run in several years now since there's not a multi-host setup available. I think the better approach is to consider the value of these tests - they're pretty difficult to read and understand in their current form - and either delete them or rewrite them to depend on a multi-host setup in Docker.

[RitaChen609]

These two tests haven't actually run in several years now since there's not a multi-host setup available. I think the better approach is to consider the value of these tests - they're pretty difficult to read and understand in their current form - and either delete them or rewrite them to depend on a multi-host setup in Docker.

I will add a ticket to review these two tests as you suggested.