feat: improved job wait_for strategies

[vanyae-cqc]

Nexus frequently has users that want to monitor a long running job (one that will take more than 10 minutes from submission to execution, sometimes as much as several days or weeks).

This PR adds some additional strategies to the wait_for function, namely:

• pure polling (HTTP GET, with a backoff)
• pure websocket
• auto (websocket before falling back to polling via HTTP GET)

Also I have set the default timeout to None, as this is what users seem to expect.

The hope being that this will handle long running jobs better than a pure websocket, which I find is often dropped if kept open for a long time.

I have also added optional logging, trying to stick to best practises for python libraries

[quantinuum-richard-morrison]

Early thoughts on the approach. I'm sorry: this proposes quite a re-write, so I've tried to justify.

If easier, we could accept that there are different ways to skin a cat and I'll pipe down and review as-is. Let me know what you think about the alternative approach I've suggested

[quantinuum-richard-morrison]

Instead of an enum a case and three functions, these could be BaseStrategy (perhaps an ABC) and three subclasses WebsocketStrategy, PollingStrategy and HybridStrategy. The advantages would be:

• users could implement their own variations easily (if they wanted to customise)
• HybridStrategy could be based on PollingStrategy with WebsocketStrategy pulled in as a mixin. Fewer lines of code (maybe) (not that that's a great metric). DRYer (hopefully)
• arguably more idiomatic python, easier to maintain and reason about

[quantinuum-richard-morrison]

(related to my other comment about using subclasses for different strategies)

The implementation of wait_for gives the user no way to choose different values for these params. They have to pass in an enum member and the code in wait_for picks a function, calling it with just the required args, so these'll always get defaults.

With a class-based approach, it could be:

class PollingStrategy(BaseStrategy):
    ...
    backoff_factor: float = 2.0
    ...

and then a user could (if they chose) do:

class MyCustomPollingStrategy(PollingStrategy):
    backoff_factor: float = 1.5

and they could pass that to wait_for

[quantinuum-richard-morrison]

Great idea