Fix overhead of DAGCircuit.remove_op_node

[mtreinish]

What should we add?

Right now the DAGCircuit,remove_op_node function has quadratic overhead as a function of the number of bits/dag edges are on an operation. This is do to how the underlying rustworkx.PyDiGraph.remove_node_retain_edges method is used by remove_op_node. Normally this doesn't matter because in most cases this is only ever called on operations with 1 or 2 qubits. However, since the introduction of #10323 this is now getting called on a barrier of n qubits for the the width of the target backend. This can become a large performance bottleneck, for example when targeting a 60k qubit backend calling remove_op_node took 47 min while it was processing the list of qubits.

To fix this optimally we'll need to likely add a new interface to rustworkx to handle this more efficiently.

[jakelishman]

Fwiw I have a proof of concept patch to rustworkx and Qiskit locally that solves this, but the issue is to remind us to sort it out properly after the 1.0 release.

[jakelishman]

See Qiskit/rustworkx#1083 for the Rustworkx side of this, which is the non-trivial part. If that (or something like it) merges there, the changes on the Qiskit side are pretty trivial - we just need to swap DAGCircuit.remove_op_node to use remove_node_retain_edges_by_{id,key}, where we can use by_id if we've got rid of the equality properties of Bit, and by_key if we haven't (or if we have other things in the wires).

[jakelishman]

Ha, I forgot we had the issue and opened #12156 to remind myself about it as well. Oh well.