Migration guide for providers to implement V2 primitives

[ElePT]

This is a proposal for content to address #2469. After a brief discussion with @jyu00 we agreed that we should focus this migration guide on showing how to implement new primitives for providers. However, I have not been involved in all discussions regarding the vision for this migration (and conversations around backend.run tend to raise a lot of different opinions) so I would appreciate confirmation that the content proposed fits the direction we want to show.

The page is currently in a pretty raw state, missing formatting, API ref links, a review on the titles, capitalization, etc, but I wanted to open a PR as fast as possible to ask for opinions on including the backend primitive wrappers as a tool for provider migration. This idea came from inspecting the only instance I know of external provider beyond the immediate product sphere, which is https://github.com/qiskit-community/qiskit-aqt-provider/tree/master, and subclasses backend primitives to expose their own primitive implementations. Following this, I decided to structure the page as follows:

• motivation: @jyu00 mentioned this was often requested by users, I tried to keep it short and touch on the usefulness of the abstraction level of the primitives
• Backend primitives as a migration alternative for providers that already implemented backend.run (following the AQT example)
• Custom primitives as an alternative for providers that want it, or didn't implement backend.run (following the StatevectorSampler and StatevectorEstimator) examples

Please let me know if you have any other take on how the content should look like @javabster, @jyu00.

[qiskit-bot]

One or more of the following people are relevant to this code:

• @javabster

[jyu00]

I think the very first paragraph should mention whom this migration guide is for, since it'd be irrelevant to the majority of people that consume IQP docs.

[jyu00]

I'd put the links to the migration guides in its own section, so the structure becomes

• why you should implement primitives interface
• how you implement primitives interface
• what you can tell your users

[jyu00]

I'm a bit confused by this section... this reads like the target audience is people who use 3rd party providers, and not the providers themselves (e.g. users of IonQProvider and not IonQ itself).

[ElePT]

I am not too set on having this section, to be honest, that's why I mentioned in the PR description that I wanted a second opinion on this approach. I based it on the only kind of external (still mostly IBMers) provider that I know implemented primitives, that is: https://github.com/qiskit-community/qiskit-aqt-provider/tree/master. They based their primitives on the backend primitives as shown in this example, and I thought it might be a good shortcut for other providers too, but I also think it might be too hacky. If you don't think it adds any value, it could be removed.

[jyu00]

I think we can point out backend primitives as an example, but don't explicitly say they should use it. It's also to their benefit to optimize for their hardware instead of using an out-of-box implementation.

This section would actually be quite helpful in the existing backend.run migration guide. If, for example, someone is using backend.run across Qiskit Runtime + Provider Foo and want to migrate to primitives. They can use this as an example to write to primitives interface even if Foo hasn't migrated yet.