Fix CollectCliffords to index nodes using their ids

[alexanderivrii]

Summary

Fixes #13457.

This PR changes the internal field in_degree in BlockCollector to be indexed by the ids of the nodes rather than by nodes themselves. See also #13424 for a related discussion.

In particular, this avoids hashing the nodes as python objects, both making the code faster and avoiding problems for things like PauliLindbladError coming from qiskit_aer.

Details and comments

I am not sure if this change really deserves a release note, but I have decided to add one, given that it does address a reported bug.

[qiskit-bot]

One or more of the following people are relevant to this code:

• @Qiskit/terra-core

[coveralls]

Pull Request Test Coverage Report for Build 11994394990

Details

• 8 of 8 (100.0%) changed or added relevant lines in 1 file are covered.
• 10 unchanged lines in 4 files lost coverage.
• Overall coverage increased (+0.002%) to 88.938%

---

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/expr.rs	1	94.02%
crates/circuit/src/packed_instruction.rs	2	94.1%
crates/circuit/src/dag_node.rs	2	79.7%
crates/qasm2/src/lex.rs	5	92.23%

Totals
Change from base Build 11977726745:	0.002%
Covered Lines:	79409
Relevant Lines:	89286

---

💛 - Coveralls

[mtreinish]

This is problematic, using the node ids is only safe for a single dag. If we want to switch this to be keyed on node ids we can not cache it. We could get away with the cache with the DAGNode storage because the hash and eq implementations are unique; either pre-rust dagcircuit where it was object id based or post-rust dag where this is an actual implementation. But node ids are not unique between dags and the indices are reused between dags and will refer to different nodes.

[alexanderivrii]

I see the point, but a single BlockCollector class only makes sense for a single DAG, in which case we should be fine using node ids, correct?

[alexanderivrii]

Closing this.