Ensure that clients are able to get their results even if QPU-ID accessors change

We need a way to ensure that clients are able to get their results from a job, even if the QPU-ID used to submit the job gets a new accessor.

Currently, retrieve_results uses the QPU-ID to look up the address to which it sends the get-results request. But if QPU-IDs are not uniquely correlated with result queues, then this can return an address pointing to a service that doesn't actually know about the specific job in question. In other words, if a new accessor corresponding to a different ConServ instance is added to the network after an executable is submitted but before the client requests the result, and if the client isn't using a cached accessor, then the client will be told that the job doesn't exist.

Planned solution

We will store some kind of unique accessor info in the job-handle itself, and require that for all result lookups.

Other solutions considered

• Use an accessor-caching TTL that's long enough to outlive most jobs. This reduces the risk but of course doesn't eliminate it (for instance, the client can easily save the job-ID somewhere persistent and then bounce their client; or, a job with a very high number of shots could outlive the TTL).
• Create some kind of global-result-queue mechanism, where the results for a given QPU-ID are stored in the same queue regardless of the accessor (so, for instance, simulated jobs would go to the same queue).

(relates to #336)

Start by tracing retrieve_results and how the job handle is created and used for result lookups. Review the interaction with QPU-ID accessors and related issue #336. Done means a job retains unique accessor information and clients can retrieve its results after a new accessor is added.