Fix ComputeUncompute State Fidelity threading issue

[woodsp-ibm]

Summary

Fixes #91

• Add reno (as noted below)

Details and comments

I changed the logic so that the sampler.run is done in the main thread and the resulting job and result is processed for the fidelity result in a separate method that is run by the thread executor of the algorithm job. This new method (_call which I named to be the same as the ref. primitives) gets passed all it needs as params, self is not passed, and where that logic was using some private instance utility methods I turned these to static (they never used self anyway).

As far as an end user goes the ComputeUncompute is used just the same way. As I changed things around a little bit though any developer that might have extended the base class, for some custom fidelity, would need to update their code for the _run.

I kept the changes minimal though the presence of the _run is a little harder to justify as things are now, but I figure, if more fidelities are added going forwards that may be a better time to sort out commonality than change things around more now.

I'll add a reno once others have had a chance to look over this. It would note the bug fix and point out the change to _run should anyone happen to have made their own fidelity off the base.

[coveralls]

Pull Request Test Coverage Report for Build 6770948050

• 16 of 16 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.01%) to 90.566%

---

Totals
Change from base Build 6769040683:	0.01%
Covered Lines:	6461
Relevant Lines:	7134

---

💛 - Coveralls

[ElePT]

Thank you very much for looking into this. I now know that the use of self is not a very good friend of multi-threading, but didn't see it as an issue at the time. As also mentioned in #93, I think that the primitives interface will change anyways, so I am ok with keeping the current _run as-is and revisiting the fidelities architecture once the primitives are settled. Unless @Cryoris has any issue with it, I would go ahead with the reno.

[woodsp-ibm]

Its not so much about self itself more that it refers to a mutable object and if the thread can read values that are changing in the main thread context... Passing whatever values more directly to that the function, which runs under the thread, makes things explicit rather than passing a reference to a larger object and letting it have at it, and the values are fixed on the stack. To me its more playing it safe, and hopefully, if any future changes might be made, doing things explicitly like this is clearer etc. Of course if one of those values, is really a reference and again mutable, and might be changed on other contexts/threads before/while used, you are back towards passing self....

[ElePT]

I think that we can go ahead and merge the fix to reduce the flakiness of the tests. And maybe reconsider if any objections come up in the future.

[woodsp-ibm]

I think that we can go ahead and merge the fix to reduce the flakiness of the tests.

Of course its not only the tests here - if users do multiple jobs in parallel they are likely to hit the same issue as the test does.