Description
What is the expected feature or enhancement?
In qiskit 1.0.0 a new kwarg version was added to the qiskit.qpy.dump() function (see: Qiskit/qiskit#11644 for the implementation). This flag enables the qiskit.qpy.dump() function to emit QPY at older versions. This can go back to the minimum compatibility version, which for the 1.x release series is QPY version 10 (which is the version emitted by Qiskit 0.45.x and 0.46.x). This means we no longer need to keep a vendored fork of the qpy module in qiskit-ibm-runtime because we can rely on the qiskit dump() function to emit an older version for us instead of purposefully holding back the qpy version via a fork.
However, besides just deleting the fork, this opens up the opportunity to do version negotiation between the client and server side. Qiskit has two attributes qiskit.qpy.QPY_VERSION and qiskit.qpy.QPY_COMPATIBILITY_VERSION which represent the maximum and minimum QPY dump versions (load() supports all versions up to QPY_VERSION) supported by the installed qiskit (all the intermediate versions are supported too). If we were to add a an API that returned the maximum supported QPY version on the server side, then qiskit-ibm-runtime would be capable of determining what value it should set the version kwarg on qiskit.qpy.dump() to to ensure that the submitted QPY payload is compatible with the server. However, even if there isn't an API to query the QPY supported versions at first, we can still delete the fork and just manually the version flag.
Acceptance criteria
Whenever we're ready to set the qiskit requirement to qiskit>=1.0.0. For the version negotiation piece we'll need a new API to expose the maximum QPY format version accepted by the server.