Add tutorials job to CI

[mtreinish]

Summary

This commit adds a new job to run the qiskit tutorials in CI. The
tutorials are used as a form of upgrade testing to ensure that for key
examples Qiskit as a whole is N and N+1 releases. This caused friction
during the qiskit 0.20.0 release because the tutorials were never
updated to stop using deprecated code (or in the case of other elements
by merging backwards incompatible changes). To ensure there aren't any
surprises at the last minute when we run the tutorials with a proposed
new metapackage this commit adds a job to CI to ensure that they always
run with terra changes. It means for PRs that change an api (after a
deprecation cycle) the tutorial will need to be updated first. This will
ensure that users will have an upgrade path because CI in
qiskit/qiskit-tutorials runs with the metapackage.

Details and comments

[mtreinish]

The merge of #4593 has broken the tutorials and this PR since the tutorials were not updated about that deprecation. This is the exact situation we need this job for. As an aside I personally feel like we should have kept that deprecation longer than the minimum, qiskit.extensions was a long lived path and we should be conservative and keep it around longer to give users a sufficient chance to migrate.

[kdk]

I think this is a good idea. Since, the tutorial job runs tutorials master against the last released qiskit, and this job runs terra master against tutorials master, is there a risk of a change (other than a breaking change) can't be moved forward in either terra or the tutorials without pushing through a failing CI?

[1ucian0]

Current error is because Qiskit/qiskit-tutorials#990 with a pending PR Qiskit/qiskit-tutorials#999

[mtreinish]

I think this is a good idea. Since, the tutorial job runs tutorials master against the last released qiskit, and this job runs terra master against tutorials master, is there a risk of a change (other than a breaking change) can't be moved forward in either terra or the tutorials without pushing through a failing CI?

I don't think so. There are 3 ways I can see this failing

1. we change the tutorials in Qiskit/qiskit-tutorials a forward incompatible manner which is possible but unlikely (given the rate of change and the kinds of changes made) in this case we would just revert that tutorial change.
2. we open a PR making a backwards incompatible change in terra where we break either a tutorial or a downstream dependent used in the tutorials. This case is what this job is here to catch because we want to ensure we don't break things for users without deprecation prior to removal. Basically we want to enforce for any version N that there is a way to write code that will work for N and N+1. When we do break an api, like in a deprecation removal we'll need to update the tutorials or other elements first which is something we want to do anyway.
3. an upstream dependency changes breaking things in an unexpected manner. This shouldn't result in a bidirectional depdency to resolve on either one we should be able to pin to an old version in either CI to workaround it

This job is just really to mirror the upgrade testing using tutorials we already have on Qiskit/qiskit to block metapackage releases that are backwards incompatible. It was what caught all the issues in qiskit 0.20.0 and why it took so long to release because I had to push out aqua, aer, and terra patch releases to fix backwards incompatibilities (for aqua) and bugs (for aer and terra). But that Qiskit/qiskit job should block the potential risk of PR gridlock because we can't bump the metapackage without have the tutorials work.