Support executor + noise_learner_v3 schema v0.2

[rainerschoe]

Summary

ibm-quantum-schemas will soon introduce new schema versions v0.2 for executor and noise-learner.

This PR will use the new schema version in runtime-client to encode the input and decode the output for those programs.

Details and comments

I replaced v0.1 with v0.2, as I did not see a reason for still supporting v0.1 after v0.2 is released. Not sure if this assumption is correct, as there were some counter-indications in the structure of the code.

Fixes #

[rainerschoe]

TODO: this currently points to a feature branch. After this is merged, we should point this to a commit on main

[rainerschoe]

This function is not needed except in unit-tests. Does not look like production code. Should we move this into tests directory?

[rainerschoe]

This function is not needed except in unit-tests. Does not look like production code. Should we move this into tests directory?

[rainerschoe]

What is the idea of this dict? I could not see a reason to support multiple decoders as part of this PR.

[ihincks]

It is common for users to submit a job in one version of qiskit-ibm-runtime, and then wish to re-download the result by job id later in time (possibly months later) to look at it again. Without this dispatch table, they'd have to look around for a compatible qiskit-ibm-runtime version and forcefully downgrade in order to see their data. If they wanted to do some kind of A/B comparison of old data vs new data, they wouldn't be able to easily do it within a single Python environment.

In short, the user experience would effectively feel like a breaking change between minor versions in certain data analysis workflows.

This is not symmetric in that we do not need to maintain multiple encoders because this same argument doesn't apply. think @mtreinish may have advocated in the past to do so (I'll let him correct me), but whatever those reasons, they I imagine that they are different than the above.

[rainerschoe]

Currently I am stuck at a transpiler test failing.
Might be caused by new qiskit being pulled in:

ERROR: test_transpile_mock_backend (test.unit.transpiler.passes.scheduling.test_scheduler.TestALAPSchedulingAndPaddingPass.test_transpile_mock_backend)
Test scheduling works with transpilation.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/rschoe/qiskit-ibm-runtime/test/unit/transpiler/passes/scheduling/test_scheduler.py", line 3222, in test_transpile_mock_backend
    with qc.for_loop((cr[0], 1)):
  File "/home/rschoe/qiskit-ibm-runtime/.tox/py311/lib64/python3.11/site-packages/qiskit/circuit/controlflow/for_loop.py", line 216, in __exit__
    self._circuit.append(
  File "/home/rschoe/qiskit-ibm-runtime/.tox/py311/lib64/python3.11/site-packages/qiskit/circuit/quantumcircuit.py", line 2920, in append
    base_instruction = CircuitInstruction(operation, (), ())
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: failed to extract enum ForCollection ('PyRange | List')
- variant PyRange (PyRange): TypeError: failed to extract field ForCollection::PyRange.0, caused by TypeError: 'tuple' object cannot be cast as 'range'
- variant List (List): TypeError: failed to extract field ForCollection::List.0, caused by TypeError: 'qiskit.circuit.Clbit' object cannot be interpreted as an integer

Note: CI fails on something else, root-cause beeing Schema points to a pre-release version of qiskit. I guess this will fix itself once things get released.

[TsafrirA]

Like yourself, I am also a bit puzzled by the backward compatibility here.
Generally speaking, I believe we wanted qiskit_ibm_runtime to be able to emit (at least a sub set of) previous schema versions (in case the server side doesn't support a given new version). Given this is not an officially released version of qiskit_ibm_runtime I am not sure if we want to be this strict, but it does create a race condition between this PR and the server side PR and deployment. Note that this branch is the only active interface with Executor and NoiseLearnerV3.

[yaelbh]

About decoders of quantum programs, be aware of this open PR: #2530

This PR is still open, so I'm note sure if it will be eventually approved and merged.