Aerospike Java client TIMEOUT error propagation when cancellation is requested

When a synchronous Aerospike operation exceeds the socket timeout, the Java client throws an AerospikeException with resultCode AerospikeResultCode.TIMEOUT and the message 'Timeout' (error code -1).

If the operation is cancelled via Future.cancel(true) on the asynchronous client, the client attempts to interrupt the underlying Netty thread, but the interruption does not reliably abort the in‑flight request, leaving the outcome dependent on server processing time and the configured retry policy.

The current implementation treats cancellation as a non‑retryable timeout, forcing users to manage retries manually, yet it is unclear whether cancellation should be considered fatal or retryable.

Does cancellation abort ongoing retries? Should cancellation be treated as a fatal error that prevents further retries? How does the client differentiate between socket timeout and total timeout when cancellation is requested?