Chunk by feature set rather than crates

[Oppen]

Crates dependencies tend to have an upper bound: as many as --all-features depends on.
However, combinations grow quadratically with the number of features to test.
Thus, it's much more valuable in terms of CI running times to split the total combinations into a given number of chunks so those can be run in parallel.

[robertbastian]

The tradeoff here is that splitting crates over multiple chunks requires building all (non-optional) dependencies in both chunks.

[Oppen]

It doesn't necessarily have to be one or the other though, it can be two different flags. On my use case we don't fill the disk, but the amount of features makes our pipelines take two hours, which severely limits our ability to iterate.

[plankton6]

We have the same problem. We only have one crate with multiple features that takes too long. I was expecting that cargo-all-features would split the whole list of feature combinations in N chunks that could be parallelised, but it was not working as expected.

As an example, this is how I was expecting this to work with Gitlab CI:

check:features:
  stage: check
  parallel: 4
  script:
    - make CHECK_FEATURES_ARGS="--n-chunks ${CI_NODE_TOTAL} --chunk ${CI_NODE_INDEX}" check-features

But only the job 1 checks features, and all the other ones (2-4) say this:

Chunk is empty (did you ask for more chunks than there are packages?