Deprecate propagate_condition argument in DAGCircuit substitutions

[jakelishman]

Once #13506 merges, the propagate_condition argument to substitute_node_with_dag will no longer have any effect. We will be able to remove the code, and to deprecate the argument.

We could remove the argument directly in 2.0, but that would make it unnecessarily difficult to support 1.x and 2.y simultaneously, and it costs us near enough nothing to issue a Python-space deprecation on it.

[mtreinish]

On #13506 I already have it removed (I haven't pushed up the change locally yet but will soon). I was thinking we should deprecate it in 1.4, you were thinking we should keep it for all of 2.x?

[jakelishman]

Once the condition code is gone, we can just ignore the argument at no cost to us. Seems better to me to then keep it through the 2.x series, so it's easier to support 1.x and 2.x simultaneously for a transpiler pass during the cross-over - you don't have to do dynamic setting of the propagate_condition argument.

I feel like the effects of all the warnings we get from Aer are more indication that deprecations should probably be staged a bit more: users need time to adjust to the deprecations, but libraries still need to support deprecated code and beyond, so to me there's an argument that the "consumption" methods should get deprecated only once they've become no-ops, where possible.

[1ucian0]

Am I understanding this correctly and this issue to 2.1 milestone? Or do. we want to introduce this deprecation in 2.0?

[jakelishman]

Depends what we decide to do with Matt's PR, but in my world, we'd issue the deprecation in 2.0. The alternative ("don't use Instruction.condition on non-control-flow ops") has been around since before the 1.0 days, and in 2.0, the option won't have any effect.