fix: retry result uploads instead of silently losing them (#504)

[gibiw]

Related #504.

Problem

QaseTestOps._send_results cleared self.results when it started the upload thread, not when the server confirmed the batch. A failed upload therefore destroyed its own results: they were in neither self.results nor self.processed, so get_results() could not see them and the local fallback could not recover them. The thread raised, pytest downgraded it to PytestUnhandledThreadExceptionWarning, the run was marked complete, and the process exited 0.

Reproduced with a local harness: 205 of 305 results lost behind an "all passed" summary, with the run showing as complete.

Changes

• Send ResultCreate.id. Result already generated the UUID; it was dropped when building the payload. The backend substitutes a random hash when the field is absent, so this had to land before retries or every retry would duplicate results.
• Retry uploads on transport errors and 408/429/5xx, with exponential backoff. Never on 400/401/403/404/413/422/507 — those fail identically on a second attempt. Retry-After replaces the computed backoff, which matters because Qase answers 429 with ~60s.
• Pin Configuration.retries = 0. It was None, so urllib3's defaults applied and would have multiplied with the application policy — a 3-attempt policy issuing 9 requests, the opposite of what is wanted on a 429.
• Set a request timeout. There was none, so a stalled connection hung the session at teardown until CI killed the job.
• Report unrecoverable batches. Loss is counted and logged with the count, and the run is left open rather than marked complete over partial data.
• Lock count_running_threads, since the completion decision now depends on it.
• Same treatment for testops_multi.py, per project: one project's loss no longer blocks the others from completing.

New config under testops.api (defaults shown), with QASE_TESTOPS_API_* overrides:

{"testops": {"api": {"timeout": 30, "retries": 3, "retryBackoff": 2}}}

retries: 3 means three attempts in total; retries: 0 sends once without retrying.

Verification

Fault injection against a fake Qase server, 305 results, batch size 50:

Scenario	before	after
no faults	305	305
connection reset	205 (100 lost)	305
resets wider than the retry ladder	50, run completed	50, run left open
429 with Retry-After	205 (100 lost)	305
500 after a partial store	255 (50 lost)	305, 0 duplicates, 50 deduplicated
server never responds	never terminated	terminates, 305
connection reset under -n 4	205 (100 lost)	305

The partial-store row is the idempotency check: the retry re-delivers 50 results the server already holds, and they are recognised by id instead of being stored twice. Without the first commit that row would read 50 duplicates.

287 tests pass in qase-python-commons, 105 in qase-pytest.