Config schema

[bentsherman]

Close #4200

Adds a helper method to check a config scope for invalid options. Since config options are defined in a dynamic and distributed manner, this approach allows them to be validated in the same way.

Enabled with NXF_ENABLE_STRICT_CONFIG. Use NXF_ENABLE_STRICT to turn the warning into an error.

TODO:

• docker, singularity, etc
• executor
• mail
• notification
• wave

[netlify]

✅ Deploy Preview for nextflow-docs-staging canceled.

Name	Link
🔨 Latest commit	d284d1c
🔍 Latest deploy log	https://app.netlify.com/sites/nextflow-docs-staging/deploys/65e1723a9d318c0008c26084

[pditommaso]

This is a big work but I don't think it's worth of. The plan is to rely on an alternative configuration mechanism providing a built-in type system

[bentsherman]

Agreed 👍 this PR will be a good reference for the config overhaul

[bentsherman]

Rebooting this PR since we didn't go with the Micronaut config. Instead I am trying a custom annotation approach so that the config schema can be typed.

I got it working for a few config scopes but there are currently two challenges:

• The @ConfigOption must be declared on a class field or method, but not all config scopes are defined this way. For this I think we just need to define a proper class for each config scope.

• The plugin system is used to collect all config schema classes, including from plugins. But if the plugin (e.g. nf-amazon) isn't already loaded when the config is validated, the config schemas in that plugin won't be detected. So we may need to load plugins based on config settings (e.g. plugins spec, aws scope, etc) after the config is parsed but before it is validated.

Anyway, just wanted to get a basic prototype working. I think we can address these challenges if we decide to keep and improve the Nextflow config format rather than move to a new one. Micronaut config and picocli should be good sources of inspiration for any bells and whistles we might need.

[bentsherman]

Closing in favor of #5816

Some of this code may be useful later if/when we want to unify the ConfigScope classes with existing config classes (CondaConfig, Manifest, etc).