Refactor Z2Symmetries

[mrossinek]

What should we add?

The Z2Symmetries are the last piece of code coupling the algorithms and application modules to qiskit.opflow instead of qiskit.quantum_info. Refactoring that class to be based on SparsePauliOp instead of PauliSumOp will allow us to remove this final dependence and, thus, will clear the path towards deprecating qiskit.opflow.

To solve this, we need to do the following:

• refactor Z2Symmetries based on SparsePauliOp instead of PauliSumOp (should be fairly trivial)
• move it to a location outside of qiskit.opflow. I am open for suggestions on where to put this. Maybe even qiskit.utils?
• I vote for the deprecation/removal of TaperedPauliSumOp without a replacement. This class merely combines the operator with its identified symmetries in one object, but this is actually never used in neither Qiskit Terra nor Qiskit Nature. And since this will rather become a utility explicitly called by an end-user to find certain symmetries, they can manage the storage of these symmetries themselves anyways, without artificially nesting them in some operator subclass.

[jakelishman]

If it's quantum-info related and uses only quantum_info classes, perhaps somewhere in qiskit.quantum_info makes most sense?

Ideally I'd like us to avoid putting more calculation code in qiskit.utils - it's in a weird state right now where it's both the bottom of the package stack (things like the lazy optional checkers and deprecation utilities) and the top of the stack (QuantumInstance, error mitigation). The top-of-stack bits largely came from the Aqua and Ignis migrations, which is understandable, but now it causes long import cycles that frequently trip us up.

[mrossinek]

I guess one option would be something along the lines of qiskit/quantum_info/analysis/z2_symmetries.py
which in turn contains the Z2Symmetries class we currently have in opflow (or an improved version thereof).

[Anthony-Gandon]

@mrossinek, I can work on this isssue