[PASQAL] Add pasqal clients retry policy

[sarjevane]

Description of Change

• Add PASQAL's pasqal_common package containing common retry logic
• Apply retry policy for both pasqal-local and pasqal-cloud
• Disable retry policy using environment variable (for e2e tests) using QRMI_PASQAL_RETRIES_DISABLED=1
• Handle two classes of retries:
  • rate-limiting (423/429) with handling of Retry-After, defaults to jitter / exponential backoff, max 5 minutes
  • transient errors (5xx) - with jitter and exponential backoff, max 2 minutes

Checklist ✅

• Have you included a description of this change?
• Have you updated the relevant documentation to reflect this change?
• Have you made sure CI is passing before requesting a review?

[CLAassistant]

All committers have signed the CLA.

[badtst]

LGTM, I'd suggest adapting the way we match against the QRMI_PASQAL_RETRIES_DISABLED env variable for usage with the qrmi_config.json

[badtst]

lgtm ! Waiting for feedback on the variable name

[badtst]

An opinion on the naming @MatthieuMoreau0 @awennersteen ?

[MatthieuMoreau0]

An alternative suggestion: instead of activating/disabling retries with a boolean env variable, have you considered using this to define the maximum number of retries? It can be set to 0 to disable retries but can also be tweaked for finer controls over the retries

[awennersteen]

I like Matthieus suggestion.

[sarjevane]

I had not considered the amount of retries, only the time budget, given the initial use-case - retry in case of transient errors to the Cloud.

IMHO a time budget (as a single value) is easier to reason with than an initial delay + exponential backoff + number of retries, so we could make the time-budget configurable (instead of simple on/off switch) - that would be my preference.

We can otherwise configure the number of retries, but that alone is only half of the story, we probably would need to make the initial delay configurable - but that feels like over-engineering to me, most users will not tweak these much.

Happy to discuss this further offline

[sarjevane]

We now have a unified Middleware, which uses retries. If the number of retries is set to 0, then there is no retries (also in case of 429)

[sarjevane]

The only failure is a timeout on the schedmd/slurm website which is down at the moment - https://github.com/qiskit-community/qrmi/actions/runs/29724719180#summary-88297102759 - unrelated to the changes of this PR.

---

Edit: schedmd's website is back up, re-running the failed test fixed it.