job_extra, extra and env_extra naming could be improved

• job_extra -> job_header_extra
• env_extra -> job_script_extra? Not great, better suggestions welcome! Not sure if there is a good way to indicate that this is something which is at the beginning of the script but after the shebang and job header (and before we run dask-worker).
• extra -> dask_worker_additional_args, better suggestion welcome!

We may want to want to warn for a few releases and point to the new name parameter names, same thing for values from the config job-extra and env-extra if they are used.

[jolange]

I’d like to give this a shot soon, because I’m eager to have possible changes included in the next release.

One could easily have both and add a deprecation warning, so I would argue that there could be coexisting until a major bump.

@riedel I agree, but to my understanding, a FutureWarning would be better suited. In the used terminology, I think we want to warn “end users”, not only “other developers”. If I add a DeprecationWarning in Job and run a script instantiating a *Cluster, the warning will be suppressed by default. See also below this table:

Changed in version 3.7: Previously DeprecationWarning and FutureWarning were distinguished based on whether a feature was being removed entirely or changing its behaviour. They are now distinguished based on their intended audience and the way they’re handled by the default warnings filters.

[jolange]

I did not see any objection to job_extra_directives, so I assume I can move on with it?