Expose environment variables with run information in compute nodes

[DanSava]

Issue
Resolves #8515

Approach

• PR title captures the intent of the changes, and is fitting for release notes.
• Added appropriate release note label
• Commit history is consistent and clean, in line with the contribution guidelines.
• Make sure tests pass locally (after every commit!)

When applicable

• When there are user facing changes: Updated documentation
• New behavior or changes to existing untested code: Ensured that unit tests are added (See Ground Rules).
• Large PR: Prepare changes in small commits for more convenient review
• Bug fix: Add regression test for the bug
• Bug fix: Create Backport PR to latest release

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.76%. Comparing base (fbfd095) to head (31a2cfe).
Report is 15 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8540      +/-   ##
==========================================
+ Coverage   90.68%   90.76%   +0.07%     
==========================================
  Files         342      342              
  Lines       20933    20945      +12     
==========================================
+ Hits        18983    19010      +27     
+ Misses       1950     1935      -15     

Flag	Coverage Δ
gui-tests	75.82% <77.77%> (+0.04%)	⬆️
integration-tests	53.95% <77.77%> (-0.05%)	⬇️
unit-tests	68.78% <100.00%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sondreso]

I think another approach that is possible here is to send in system env vars to forward_model_data_to_json and join them with the user specific ones. Then it will be very explicit what the source of the env vars are.

[DanSava]

I think another approach that is possible here is to send in system env vars to forward_model_data_to_json and join them with the user specific ones. Then it will be very explicit what the source of the env vars are.

Done

[yngve-sk]

LGTM, env vars written to jobs.json env entries via create_run_path seems like a sensible way to do it