`GroundStateEigensolver.solve()` should be async and return a job id when using real backend

What is the expected enhancement?

Even with Qiskit Runtime, a typical VQE program can take more than one hour to run on a real backend, plus queue time. The currently workflow where result has to wait until solver.solve(problem) is done is not very friendly for real backend. I would like to suggest a new workflow that is similar to backend.run(circuit) for running QASM jobs.

Current workflow

runtime_vqe_groundstate_solver = GroundStateEigensolver(qubit_converter, runtime_vqe)
runtime_vqe_result = runtime_vqe_groundstate_solver.solve(problem)

Proposed workflow

runtime_vqe_groundstate_solver = GroundStateEigensolver(qubit_converter, runtime_vqe)
runtime_vqe_job = runtime_vqe_groundstate_solver.solve(problem)
runtime_vqe_result = runtime_vqe_job.get_result()

Or create a new method submit_job (or other names) if we don’t want to break current API.

runtime_vqe_groundstate_solver = GroundStateEigensolver(qubit_converter, runtime_vqe)
runtime_vqe_job = runtime_vqe_groundstate_solver.submit_job(problem)
runtime_vqe_result = runtime_vqe_job.get_result()

[mrossinek]

I think now that the refactoring to the primitives is complete, this issue can be closed.

As per the runtime session question, this is off-topic for this thread and (if not yet answered via other channels) should be picked up elsewhere 👍

[woodsp-ibm]

I will note that the intent going forwards is to move the algorithms over to using the primitives. At this point primitives define an interface and whether they are purely local code or code going over to use some remote backend will end up at the level of the primitive. At this point I would argue the primitives more represent the fundamental interface and should ensure friendliness to the backend, whatever that means, as part of their task of improving overall performance etc