Remove RestlessMixin and deprecate restless nodes

[wshanks]

This change removes the previously deprecated RestlessMixin class and
deprecates the restless processing nodes RestlessToIQ and
RestlessToCounts. The motivation for the removals is to streamline the
remaining code base. The restless features are little used and it
remains possible to set up experiments to run in restless mode by using
a custom data processor even without support in the base package.

[wshanks]

I marked this as a draft because it depends on #1511. Also, I am not sure if we need to remove this code or not. My thinking was that along with pulse we should pull out other features that are unused to reduce the maintenance burden (more tests to run every time, more things to migrate when Qiskit and Qiskit IBM Runtime change, etc.). But looking at it it is not that much code -- the mixin is mainly one function and then there are a couple data processing nodes. Maybe we could keep it for now.

There is also the question of how useful restless measurements are now. I tried out FineSXAmplitude on current backends. On one backend (an old falcon) I saw a QPU time of 16 sec without restless versus 3 sec with restless (20 us rep delay). One a second backend (an eagle) I saw QPU times of 18 sec without restless versus 6 to 7 sec with restless (15 to 20 us rep delay). The 16-18 sec comes out to 280 to 310 us per shot. Likely that is 250 us rep delay plus 2-4 sec of overhead. So the restless case is still around a 10x speed up not counting the few seconds of overhead present on every job. So qubit reset has not quite made restless measurement redundant so far.

[wshanks]

After some further testing, I lean again towards following through with removing the restless code. Previously I had found the following results on an eagle system (using FineSXAmplitude):

• Default rep_delay, init_qubits=True: 17 sec qpu time
• Enable restless with 15 us rep delay, init_qubits=False: 6 sec qpu time

I realized that this was not a fair comparison because enable restless is reducing the rep delay to faster than the default. I tried a new case:

• Rep delay of 5 us, init_qubits=True: 6 sec qpu time

With init_qubits=True, the rep delay can be shorter than the restless case without an error. The results for the different cases are within +/-4e-3 d_theta error. There may be some small bias between the cases but more statistics would be needed. The amplitude of the signal is smaller for the restless case.

From this we see that there is no significant reduction in qpu time by using restless over what can be achieved with init_qubits=True and a shorter rep delay. Additionally, with init_qubits=False like restless uses, rep delays shorter than 15 us resulted in errors while I could go down to 5 us (did not try shorter) without error for init_qubits=True. This error should be addressed in future updates to the IBM service but it shows that the restless path is not well supported and supports separating it out of the base package. The default behavior of enable_restless is to choose the shortest possible rep delay which currently leads to an error.

[nkanazawa1989]

Thanks for simplification of the codebase and some quantitative analysis. I also think these experimental techniques should go to separate repositories, like addons. In this sense, I'm fine with removing the restless module regardless of how it works with IBM devices.

I could go down to 5 us (did not try shorter) without error for init_qubits=True

This result is a bit surprising. Since IBM Quantum doesn't explain qubit reset mechanism, we cannot discuss further. I'm also curious how this configuration works for RBs.

[wshanks]

This result is a bit surprising. Since IBM Quantum doesn't explain qubit reset mechanism, we cannot discuss further. I'm also curious how this configuration works for RBs.

The errors I was seeing for short rep_delay with init_qubits=False were overflow errors from the qubit measurements being spaced too closely together in time for the system to process them. The way I interpreted the results is that the qubit initialization gets counted as part of the circuit and rep_delay is just the idle time in between the end of one circuit and the start (including initialization) of the next. So using init_qubits=True adds to the circuit duration and allows a shorter rep_delay without getting overflow errors because the time between measurements is still spaced far enough apart. The duration of qubit initialization is not reported but it can be inferred that it is a fraction of 250 us, since that is the default_rep_delay and using a rep_delay of 5-15 us results in roughly the same QPU time for init_qubits=True and init_qubits=False.