Remove `source` from `install_jobs` section in Everest config

[oyvindeide]

Is your feature request related to a problem? Please describe.
When users have to install custom jobs, they have to add them to the install_data-section:

install_jobs:
  - name: forward_model
    source: r{{configpath}}/../input/forward_model

where source points to a file, which is typically just EXECUTABLE forward_model.exe, but can also have some other config options.

This causes the user to have to manage extra external files.

Describe the solution you'd like
This should be inlined into the install_jobs section with no need for an external file:

install_jobs:
  - name: forward_model
    executable: r{{configpath}}/../input/forward_model.exe

the optional settings, stdout_file, stderr_file etc. should also be possible to configure here. We should be able to use the dataclass from ert directly:

ert/src/ert/config/forward_model_step.py

Line 100 in 95ac0fa

class ForwardModelStep:

, so we get the same, or better validation then we currently do.

After this change, we should still parse the deprecated source for a while, notifying the users that it is deprecated, and show them what the new configuration should look like, for the example above:

The source keyword in install_data is deprecated, you should instead do:

install_jobs:
  - name: forward_model
    executable: r{{configpath}}/../input/forward_model.exe

Does not have to be that exactly, but something along those lines.

[roliveira]

I expect the user installed jobs to be fewer compared to the system installed jobs, and as in the suggestion of #9615 (example below), having the explicit links to executables, might render the whole section obsolete in the future.

Example from #9615:

simulation_jobs:
- r{{configpath}}/../input/forward_job.py --input coordinates.json --output objective

[oyvindeide]

After discussion we found that it would be best to keep the job format, and not go straight to the command line, one of the arguments is that using the command line syntax directly might come with expectations that everything from the command line would be valid, including pipes etc. Dont think we want to support that, so will keep to the job format, at least in the short term.

[roliveira]

expectations that everything from the command line would be valid

Thanks for the clarification!