Add consumableResources process directive for AWS Batch

[robsyme]

Summary

• Add consumableResources process directive that maps to AWS Batch resource-aware scheduling
• Enables license-seat-aware job scheduling — AWS Batch holds jobs in RUNNABLE until consumable resources are available
• Supports string shorthand (consumableResources 'my-license' implies quantity 1), map syntax (consumableResources 'lic': 2), and is repeatable across multiple calls

Usage

process runDragen {
    consumableResources 'my-dragen-license'
    cpus 4
    memory '16 GB'

    script:
    """
    dragen --ref-dir /ref ...
    """
}

Implementation

• Core module: Directive registered in ProcessBuilder.DIRECTIVES, handler methods for string/map syntax with ConfigList accumulation, TaskConfig.getConsumableResources() getter normalizing all input forms
• nf-lang: ProcessDsl.DirectiveDsl updated for config validation
• nf-amazon plugin: AwsBatchTaskHandler.configJobDefRequest() maps directive to ConsumableResourceProperties on RegisterJobDefinitionRequest via RegisterJobDefinitionModel; included in job definition hash
• Docs: Full directive documentation in docs/reference/process.md with FIFO queue ordering caveat; added to AWS Batch executor's supported directives list

Closes #5917

Test plan

• ProcessBuilderTest — string shorthand, map syntax, multi-resource, repeatable accumulation
• TaskConfigTest — Map normalization, List passthrough, String shorthand, null handling
• AwsBatchTaskHandlerTest — single resource, multiple resources, absent directive, hashing, no regression on existing tests
• Full nf-amazon plugin test suite passes
• Core module smoke tests pass (3 pre-existing failures unrelated to this change)
• Live validation with AWS Batch consumable resource

🤖 Generated with Claude Code

[netlify]

✅ Deploy Preview for nextflow-docs-staging canceled.

Name	Link
🔨 Latest commit	66a336a
🔍 Latest deploy log	https://app.netlify.com/projects/nextflow-docs-staging/deploys/69c1aba5a98cf00007690024

[pditommaso]

i'd prefer mapping this to a custom resource label instead of introducing yet another directive

[robsyme]

Re: resource labels - interesting approach.
I had considered resourceLabels as a way of tagging infrastructure pieces - a write-only feature - not something that would hold up or modify the execution.

[robsyme]

And to confirm - I have tested this one using real consumable resources.

... which causes the jobs to wait as expected:

[bentsherman]

@pditommaso if we implement this with a resource label, we'll have to think about how to namespace it properly. Let me know what you think:

// alt 1
resourceLabels 'consumable-resource:my-dragen-license': 1

// alt 2
resourceLabels 'consumable-resource': 'my-dragen-license=1'

[pditommaso]

Maybe more the second, tho don't have a strong opinion, we should eval pros & cons of different syntax, including the need for sched.

Another option to avoid overloading the resourceLabels directive could be to introduce a dedicated one named hints or computeHints, or something along those lines

[bentsherman]

I really like the idea of a hints directive or something like that. Same structure as resourceLabels but avoids the unintended side-effect of extra labels

[robsyme]

I'd definitely prefer hints (or similar) to overloading resourceLabels

[pditommaso]

🙌

[robsyme]

If @bentsherman or @pditommaso give me a 👍 on this comment, I'll move this PR to hints with a "consumable-resource" namespace/prefix.

[pditommaso]

Feel free to draft as non-binding. It'd be good to draft a spec/adr separately to "formalise" the new directive name/syntax etc.

[pditommaso]

** separately ** 😄

[robsyme]

Hahaha. I'll pull back the ADR and limit this PR to just the (draft) implementation

ADR (with real human input) for discussion: #6960

[bentsherman]

Closing in favor of #7034