refactor: unify snakemake versions between envs

[AngryMaciek]

Update older snakemake version for the root-dedicated conda env.

Fixes #10

[AngryMaciek]

As mentioned in #11, the GH Action for miniconda had some random problems with the installation. I have fixed that in this PR by removing the miniconda version fix in the CI workflow. It will always download the most recent one, which is good.

I updated the snakemake version in the conda env but then it required mamba too for package management within the zarp workflow (for automatic env generation). So I have added mamba as a dependency and let it run.
Now it seems that the output files while running with mamba envs do not match the expected output, but only for one tool: cutadapt:

results/multiqc_summary/multiqc_data/multiqc_cutadapt.txt: FAILED
results/multiqc_summary/multiqc_data/multiqc_cutadapt_1.txt: FAILED

This would suggest we need to use different expected output for conda and singularity executions<?>
What do you think @fgypas?

[AngryMaciek]

What I described above (#16 (comment)) is a separate issue, linked to conda->mamba improvement. I have now fixed the configuration so that we always use conda frontend, as we have always been.
That way the initial problem of snakemake versions inconsistency is resolved!
I have opened an additional issue related to upgrade to mamba: #18

[fgypas]

Sorry @AngryMaciek I did not see the notifications earlier. I will have a look at the open PRs soon.

[uniqueg]

Based on the points mentioned in the discussion, these changes look reasonable to me. Given that the tests pass, I would tend to say let's merge this. But I'm not an expert on Conda, Singularity or Snakemake execution, so I think we should wait for @fgypas review as well

[AngryMaciek]

@fgypas : could you plese review the change?

[fgypas]

Did you also test the cluster execution with the current version?

[AngryMaciek]

Did you also test the cluster execution with the current version?

Yes, the outcome is the same as for local tests.