Validate actions during their creation, store only configVersion in the Job schema

[despadam]

Based on the comment under PR #1286 and discussing afterwards with @sofyalaski:

• There is no need for method validate() in the action class. Validation should happen inside the constructor of each action.
• Since we are now using a global job configuration - instead of job specific - we should only store the configuration version inside each job in the db.
• Before create: No need for additional logic. If there is any error while constructing the actions, the application fails. When all actions have been initialized successfully, then each job that gets created will do so by automatically using the current global configuration.
• Before statusUpdate: We need to check if the configVersion is the same. If no changes were made to the configuration, then we can proceed directly to performing the update. But if the configuration has changed, would we need to update the value that is stored in the db? Note that when updating the configuration, the application needs to get restarted, so the actions have already been reconstructed automatically with the new configuration values.

[sbliven]

I'm back from my vacation and just seeing this.

Validation of the job config file needs to happen in the constructor, as you say.

The reason for the validate() method on actions was to allow validation of CreateJobDto.jobParams. For instance, one could imagine a job where users have to supply an authentication token when creating a job, which then gets validated by URLAction before making the request.

None of the MVP actions used jobParams (other than the datasetIds list) so including validate() in the abstract interface was more about future-proofing the API than from an immediate need. But if we're removing validate() then we should probably remove jobParams itself (making datasetIds a top-level field as proposed elsewhere).

[sofyalaski]

@sbliven I was thinking about that validate() function when I stumbled upon this enum JobsConfigSchema. According to this enum, job wouldn't have the jobParams, but only datasetIds, so essentially the case you propose. However, in the dto the jobParams is the required parameter. We should make it consistent. We could introduce another enum for job parameters, that would include datasetIds but I don't know what else this enum should include for now

[despadam]

configVersion in the job schema: has been resolved by PRs #1364 and #1395

TODO: validation action

[sbliven]

validate() restored in #1421