refactor: switch to using primitives in qiskit_nature/second_q stack

[mrossinek]

Summary

This refactors the entire qiskit_nature/second_q stack to use the new Qiskit primitives.

Some further changes are required:

• unify the VQE-Factory signatures with the new VQE (positional estimator, ansatz and optimizer)
  • do we want a default optimizier?
  • do we even want a default estimator?
• refactor the EigenstateResult.eigenstates once Fix VQE result, add ansatz Qiskit/qiskit#8816 is merged
• check the documentation strings for the validity after these changes

Details and comments

Closes #849

[mrossinek]

Note: Neko is expected to fail here, since I bumped the required Terra version to 0.22.*. Once the release candidate is out, this should be fixed 🤔

[mrossinek]

@ElePT @manoelmarques could either of you please take a look at updating the 12th tutorial: https://github.com/Qiskit/qiskit-nature/blob/main/docs/tutorials/12_deuteron_binding_energy.ipynb ?

[mrossinek]

I am also noticing some flaky tests which use the Estimator primitive without any shots being specified.. I thought that I am setting the algorithm_globals.random_seed everywhere and I am also providing a fixed initial_point to the VQE everywhere. So I am at a bit of a loss with regards to the tests randomly failing.

@ElePT do you have any ideas what could be causing those failures?

[mrossinek]

I realized just now that this was not a draft PR until now, so I cannot mark it as "ready for review"... So instead I'm leaving this comment to do just that 😄

There are two aspects to make note of:

• the neko integration tests will continue to fail until Terra releases some version of 0.22 (0.22.0, 0.22rc1 or whatever)
• I did not have the time to update the 12th tutorial to use primitives. I opened Update the Deuteron Binding Energy tutorial to use primitive-based algorithms #859 to postpone this to the future. It works as of now, but we should update it prior to releasing 0.5

[coveralls]

Pull Request Test Coverage Report for Build 3196983293

• 138 of 142 (97.18%) changed or added relevant lines in 20 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+0.06%) to 85.554%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit_nature/second_q/algorithms/ground_state_solvers/ground_state_eigensolver.py	9	10	90.0%
qiskit_nature/second_q/properties/occupied_modals.py	4	5	80.0%
qiskit_nature/second_q/problems/eigenstate_result.py	48	50	96.0%

Files with Coverage Reduction	New Missed Lines	%
qiskit_nature/second_q/algorithms/ground_state_solvers/ground_state_solver.py	1	92.0%

Totals
Change from base Build 3172412780:	0.06%
Covered Lines:	17086
Relevant Lines:	19971

---

💛 - Coveralls

[woodsp-ibm]

As things stands eigenstates comes from the classical Numpy solver so I am wondering why the conversion to a circuit here rather than perhaps giving back a Statevector. Someone wanting a circuit from it can always convert it themselves - is this something we use/want as a circuit?

[mrossinek]

The idea was to have a simple and consistent type for EigenstateResult.eigenstates. Namely list[tuple[QuantumCircuit, Sequence[float] | None]] meaning that it is a list of circuits + their optimal parameters (or None if non-parameterized circuit).

If a user needs the eigenstate, they can still obtain it from the EigenstateResult.raw_result object. Handling this consistently here, avoids another isinstance check when using the .eigenstates in other locations 👍