fix: apply the configured timeout and retries to API v1 uploads

[gibiw]

Related to #513 — deliberately not auto-closing it. The issue stays open until the fix is released, then gets a comment asking the reporter to try the released version.

Problem

testops.api.timeout was passed to API v2 result submission but never to the API v1 client. An attachment upload that stalled — connection open, no response, no exception — was therefore waited on indefinitely: the result batch being prepared was never submitted, the reporter thread stayed alive, and complete_run()'s while self.count_running_threads > 0 loop kept the pytest process (one pytest-xdist worker) running until CI killed it.

Because no exception was raised, send_with_retry() never had anything to retry. And attachment errors that did raise were swallowed inside _upload_attachment()'s per-batch except, so the outer retry never saw those either.

Changes

• Every API v1 call now passes _request_timeout=self.config.testops.api.timeout — attachment uploads plus get_project, get_environments, get_configurations, create_configuration_group, create_configuration, get_run, complete_run, create_run, update_run_publicity and run_update_external_issue. All of them ran without a timeout; the ones on the main thread would hang the session just as effectively.
• Attachment batches are retried through the existing send_with_retry() with testops.api.retries / testops.api.retryBackoff, the same policy as result uploads: transport failures and 408/429/5xx retried, 4xx not.
• Retry exhaustion keeps the current behaviour of logging and continuing, so the results the attachments belong to are still submitted, and the remaining batches are still uploaded.
• README documents that the timeout and retry settings cover attachment uploads; changelog and version bumped to 5.1.5. Reporter pins are ~=5.1.x, so no reporter version bump is needed.

Acceptance criteria from the issue

Criterion	Status
QASE_TESTOPS_API_TIMEOUT applied to v1 attachment uploads	done
A stalled upload is interrupted after the timeout	done — urllib3 raises ReadTimeoutError, which is_retryable() treats as retryable
Retryable attachment failures retried a bounded number of times	done — retries total attempts per batch
Retry exhaustion does not prevent result submission	done — covered by a test
A reporter thread cannot stay active indefinitely because of an attachment	done — a request can no longer block without end
All xdist workers exit after an attachment timeout	follows from the above; the thread now terminates

I deliberately did not add a bounded wait to complete_run() / complete_worker(). The unbounded request was the root cause; capping the wait would trade a hang for silent result loss and needs its own design.

Tests

New tests/tests_qase_commons/test_api_v1_client.py (13 tests): timeout propagation for each v1 call, retry of a retryable attachment failure, stopping after the configured attempts, not retrying a 4xx, and a failed batch not aborting the batches after it.

tox -e py312: 304 passed in qase-python-commons, 123 passed in qase-pytest.