Phalcon DI Shared HttpClient and External Cancellation Token Interoperability

When Phalcon\Http\Client is registered as a shared service in the DI container, the same instance is reused for every request, and its timeout setting is attached to that instance.

This means that changing the timeout for one call affects all subsequent uses unless the service is re‑defined or cloned, and the client provides no public method to abort an ongoing request based on an external cancellation signal.

The goal is to allow a long‑running HTTP call to be terminated gracefully when a higher‑level process receives a cancellation request, without leaking sockets or forcing a timeout exception.

What mechanism should Phalcon provide to expose cancellation, how can developers safely isolate timeout settings on a shared client, and should the DI container support a factory‑scoped client instead of a shared one for this use case?