platforms: use processed workflow config

[oliver-sanders]

• When retrieving the platform used by a task, use the processed workflow config rather than processing the config from scratch.
• This avoids the need to access the DB to extract template variables (workflow params) which could cause public DB locking issues.

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).
• CHANGES.md 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.

[oliver-sanders]

Kicked off Rose tests against this branch: https://github.com/metomi/rose/actions/runs/8325392017

Not playing ball because of lint tests, reviewers will need to check manually, note, 2.1.x branch. Suggest the following:

t/rose-task-run/04-run-path-empty.t
t/rose-task-run/-app-fcm-make.8

[wxtim]

• Read code change
• Checked where code is likely to touch the database using ./t/rose-task-run/04-run-path-empty
• Run test manually.

[MetRonnie]

Re-ran tests

[hjoliver]

I think this will fix a bug we've just run into at NIWA. We have a custom Python module that determines Slurm accounting code from a project code in the environment. The fcm_make Rose app is failing when it parses the flow.cylc to get platforms info, because the PYTHONPATH to the project code module isn't getting through to that process (even though it works fine for Cylc at scheduler start-up).

[oliver-sanders]

That makes sense.