Compatibility classes for converting BackendV1 to BackendV2 to facilitate migration

[chriseclectic]

What should we add?

For package developers trying to transition to new backends it would be very convenient if terra had wrapper backend classes/functions that can make a backend V1 into a backend V2 and vice versa.

Something to this effect was recently added to qiskit-experiments to help facilitate handling both types of backends in tests, however it falls a bit short of general use because it uses duck-typing of methods for both backends but wont actually be an instance of a backend so can't be used as a drop-in replacement.

It would be convenient having either a backend class or generator function that can take one backend and return an equivalent instance of the other.

Eg we could have classes that can be initialized with another backend like:

class WrappedBackendV1(BackendV1):
    def __init__(self, backend: Union[BackendV1, BackendV2]):

class WrappedBackendV2(BackendV2):
    def __init__(self, backend: Union[BackendV1, BackendV2]):

An alternative would be a function to generate a backend either V1->V2 or V2->V1 (or trivially V1->V1, V2->V2)

# function interface
def wrapped_backend(
    backend: Union[BackendV1, BackendV2], target_cls=BackendV2
) -> Union[BackendV1, BackendV2]

[jakelishman]

From a typing perspective I don't like your proposed interfaces haha (target_cls implies wrapped_backend lives in a dependent type system, and are the unions in WrappedBackend meant to keep expanding with every new spec, so the classes just get more and more ifs?), but the conversion functionality seems like a sensible addition to help migration. I'm not convinced that we can make a sensible BackendV2 -> BackendV1 converter, because BackendV2 contains much more precise information about various Target properties that can't be represented in a BackendV1, but we don't want people to keep using BackendV1 anyway, and we wouldn't provide "backwards migration" for any other new feature.

Since I complained about your proposed interface, my suggestion would be to add a single class method BackendV2.from_v1(cls, base: BackendV1) -> BackendV2. It's got stricter/safer typing, and it's read as an associated constructor of the BackendV2 class. Internally it'd probably return an instance of some private _ProxyBackendV1AsV2 type.

[mtreinish]

As for the specific details of building this most of the code already exists in the fake providers already. The majority of such a compatibility interface would be converting BackendConfiguration, BackendProperties, and PulseDefaults into a Target and assorted other instance attributes. The fake providers (plus qiskit-ibm-provider and qiskit-ibm-runtime) took some draft code I wrote for them to do that conversion several months ago to build the same converter. So having I think both potentially promoting https://github.com/Qiskit/qiskit-terra/blob/main/qiskit/providers/fake_provider/utils/backend_converter.py as more public (for external consumption in other *ibm* providers) and using that to build the interface shouldn't be very difficult.