Snakemake version 8.16.0

Describe the bug

The default behavior of cores is different and limits the number of threads for submitted jobs to the number of cores on the host machine.

I'm working on a Slurm cluster. In Snakemake 7.19.1 one could just set --max-threads to limit the number of threads used in any submitted job (say 42) and not worry about --cores (which I never used and afaik would limit the submitted total number of threads across all jobs). Now in Snakemake 8.16.0 --cores seems to grab a default value from the number of cores of the machine where snakemake was executed (say 8). And this value seems to limit the number of threads which are used to submit jobs to nodes of the cluster, which of course can have a completely different architecture (say 128 cores).

Minimal example

Take this Snakefile. We have a submitted job which wants to have 64 threads.

#print(f'workflow.cores: {workflow.cores}')

rule all:
    input:
        "result"

rule get_result:
    output:
        "result"
    threads: 64
    shell:
        "echo SLURM_JOB_CPUS_PER_NODE $SLURM_JOB_CPUS_PER_NODE > result"

Depending on the Snakemake version and (probably) the number of cores on the host machine the number of threads it actually gets can vary from 8 to 64 for the variant with --jobs=50. Here are some more results for the thread count for rule get_result in the outputs of dry run with 8.16.0, dry run with 7.19.1, wet run with 8.16.0, wet run with 7.19.1:

• snakemake: 8, 1, NA, NA
• snakemake --jobs=50: 50, 50, 8, 64
• snakemake --jobs=50 --max-threads=42: 42, 42, 8, 42
• snakemake --jobs=50 --max-threads=42 --cores 30: 30, 30, 30, 30
• snakemake --jobs=50 --cores 30: 30, 30, 30, 30
• snakemake --max-threads=42: 8, 1, NA, NA
• snakemake --max-threads=42 --cores 30: 30, 30, NA, NA
• snakemake --cores 30: 30, 30, NA, NA
  NA: impossible to submit without specification of --jobs

Uncommenting the print statement reveals that the value of workflow.cores is 8 by default (on my host) with version 8.16.0 and not set with version 7.19.1. So I assume the new behavior of cores is at the core of this issue.