runahead update on manual trigger

[hjoliver]

[scheduler]
   allow implicit tasks = True
[scheduling]
   cycling mode = integer
   [[graph]]
      P1 = """
         get => foo => bar & baz
                 foo[-P1] => foo
      """
[runtime]
   [[root]]
       script = "sleep 10"

Wait till the workflow moves on to e.g. cycle point 10, then trigger 1/foo with --flow=new.

All the foos will be spawned out to the current runahead limit before it gets updated to reflect the fact that the runahead base point has moved back to cycle point 1.

That's a bug under current intended behaviour.

However, in principle we should never reset the runahead limit backwards, at least not by default: if a new task or flow gets triggered earlier in the graph, why should we suddenly pause the main flow-front with a new, more restrictive runahead limit?

So: QUESTION

• Should we default to never settting the runahead limit backwards
• But provide a workflow setting, or a manual-trigger command option, to allow it for pragmatic reasons (workflow so big that performance is an issue for multiple concurrent flows: possibly it should be a workflow-specific thing).