Verify that deprecate_arg has not introduced message regressions

[jakelishman]

With #9865 open (possible fix in #9884), there is currently a possible regression. If an argument to be deprecated can reasonably be passed positionally and was previously handled by a hard-coded if x is not None (or similar) check inside the function body, the warning will no longer be raised. We need to ensure by some mechanism that all these warnings are being correctly raised in the Terra 0.24.

Our unit tests should have caught any regressions, but we don't necessarily have great coverage of those, and there are some examples (e.g. in #9864 and #9869) where tests of the deprecations were changed to allow a CI pass.

This issue can be solved either by #9884 or an alternative merging, or by us manually going through the current uses of deprecate_args, and reverting any places where the argument would / could reasonably be passed positionally (e.g. if it's 4 arguments deep into keyworded defaults, it's highly unlikely anyone's passing it positionally). This can be checked by searching for deprecate_arg in the code base, or alternatively the PRs that introduced most uses are:

• Apply new deprecation decorators to algorithms folder #9864
• Apply new deprecation decorators to visualization folder #9867
• Apply new deprecation decorators to transpiler folder #9868
• Apply new deprecation decorators to circuit folder #9869
• Apply new deprecation decorators to qobj and qpy #9870
• Apply new deprecation decorators to pulse folder #9871
• Apply new deprecation decorators to providers folder #9872
• Apply new deprecation decorators to quantum_info folder #9873
• Apply new deprecation decorators to dagcircuit folder #9874
• Apply new deprecation decorators to util files and folders #9875

These should be ticked when it is validated that they contain no regressions.

(the most important ones to revisit are the merged ones)

[Eric-Arellano]

Agreed. Note that this is a regression from direct calls to warnings.warn to @deprecate_arg. It is safe to migrate from @deprecate_arguments to @deprecate_arg because it had this same deficiency.

Also, @deprecate_arg is handling one edge case we were not properly handling before, when the user explicitly sets bad_arg=None. That will cause their code to break in future Qiskit versions, so it's an issue that we were not handling before. But, it was already broken, so a higher priority is probably avoiding the introduction of a new regression.

--

I'll work on your review feedback in #9884 today, and then we can decide tomorrow whether to move forward with #9884 vs. the audit you propose above.