Avoid spurious logging on restart with waiting parentless tasks.

[hjoliver]

Close #7037

If auto-spawned parentless tasks are present at shutdown, on restart they will be resurrected from the DB; and auto-spawned to the runahead limit again - because we don't record whether or not parentless tasks were spawned already.

This double-spawning is prevented (by luck - [see footnote]) by the imperfect bodge that stops suicided tasks from being resurrected by other dependencies - which has no functional effect, but it results in misleading log messages.

Said imperfect bodge was fixed by re-implementing suicide triggers as expire triggers (#6835) - but for now that's experimental.

Solution implemented here:

• if the experimental expire trigger feature is turned on on:
  • don't run the bodge (this should have been done in Reimpliment suicide trigger as expire trigger #6835)
  • (and handle the parentless-waiting-task-at-restart problem by simply not adding tasks to the pool if already added)
• if the expire trigger feature is not turned on:
  • do run the bodge (it's still needed for suicide triggers, despite being imperfect)
  • but demote the log message to DEBUG and change it slightly to work for both cases (suicide and parentless)

---

[footnote] - if the double-spawning had not been prevented by the bodge I think the new instance would just replace the old in the task pool, which would actually be fine because the task had not done anything yet (however, better not to do it).

Check List

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• Applied any dependency changes to both setup.cfg (and conda-environment.yml if present).
• Tests are included (or explain why tests are not needed).
• Changelog entry included if this is a change that can affect users
• Cylc-Doc pull request opened if required at cylc/cylc-doc/pull/XXXX.
• If this is a bug fix, PR should be raised against the relevant ?.?.x branch.

[hjoliver]

Deliberate change - it's important for users to know when tasks enter the n=0 window (otherwise it only gets logged as INFO at the first state change).

[MetRonnie]

I don't see why this is useful info to have in the logs

[MetRonnie]

Can make this shorter

Suggested change

	id_ = flow(
	{
	'scheduling': {
	'graph': {
	'R1': 'a',
	},
	},
	}
	)
	id_ = flow('a')

[MetRonnie]

I don't see why this is useful info to have in the logs

[MetRonnie]

To me it looks like the problem is that we keep calling pool.release_runahead_tasks() every time we load a single task from the DB instead of just calling it at the end of loading all tasks.

Had a go at this here (unavoidable refactoring): https://github.com/cylc/cylc-flow/compare/master...MetRonnie:runahead-release?expand=1