Use pickle __reduce__ for TwoQubitWeylDecomposition

[jakelishman]

Summary

Since this class does complicated calculation within its __new__ method (as many extension classes do), we want to use an alternative extension-module constructor for the object on unpickle, to avoid leaking the "pickle" / "no pickle" state through the default constructor.

This implements a private Python-space method that directly constructs the object from components, which is then used as the __reduce__ target, along with the pickle state.

Details and comments

Built on top of #11946, since that might be on the verge of landing. See #11946 (comment) for context.

It's plausible we might want to expose _from_state as a public constructor, or otherwise provide a convenient debugging method that produces a copy/paste codeblock in terms of it, since unlike from_bytes, it completely skips all the recalculation of the decomposition and simply builds the state in place; there's zero risk of floating-point errors from the re-decomposition, because it simply doesn't happen.

[qiskit-bot]

One or more of the the following people are requested to review this:

• @Eric-Arellano
• @Qiskit/terra-core
• @kevinhartman
• @levbishop
• @mtreinish

[coveralls]

Pull Request Test Coverage Report for Build 8283866556

Details

• 76 of 92 (82.61%) changed or added relevant lines in 2 files are covered.
• 5 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+0.008%) to 89.258%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
crates/accelerate/src/two_qubit_decompose.rs	66	70	94.29%
crates/accelerate/src/euler_one_qubit_decomposer.rs	10	22	45.45%

Files with Coverage Reduction	New Missed Lines	%
crates/accelerate/src/euler_one_qubit_decomposer.rs	1	91.05%
crates/qasm2/src/lex.rs	4	91.69%

Totals
Change from base Build 8282173373:	0.008%
Covered Lines:	59547
Relevant Lines:	66713

---

💛 - Coveralls

[levbishop]

Looks like a better way to do things for pickle.

Not sure that I agree for exposing this to from_bytes: although a discrepancy between the original and reconstructed state does indicate a floating point error, it may equally likely be an error in the initial decomposition giving a chance to fix it at the re-decomposition? Neither seems obviously better to me, and at least with the current re-decomposition the numerical stability gets checked in the test suite.

[jakelishman]

We can check numerical stability by just trying to do the same decomposition more than once, right? TwoQubitWeylDecomposition(u) == TwoQubitWeylDecomposition(u) would be a more thorough attempted check of that, than the from_bytes method that requires quite a lot of separate code to maintain to make it work. That's got easier with the Rust-space version of things, since now we don't have to dance through __new__ quite so heavily to handle subclassing, but I'd argue that our debugging tool not being a direct bitcopy reproduction is actually really painful. Checking for numerical stability is a good thing for the test suite to do for sure, but having it be a required part of reconstructing the object at all is not great for debugging, I think.

[jakelishman]

Now rebased over main, as #11946 merged.

[mtreinish]

LGTM, this is a cleaner solution to handle pickling without having to worry about duplicate calculations.