Improve features dev-ex

[ggwpez]

Adds a config file that allows to run zepter without any arguments in the workspace to address all issues.
A secondary workflow for the CI is provided as zepter run check. Both the formatting and linting are now in one check for efficiancy.

The latest version also detects some more things that featalign was already showing.

Error message in the CI now looks like this:

...
crate 'test-parachains' (/Users/vados/Documents/work/polkadot-sdk/polkadot/parachain/test-parachains/Cargo.toml)
  feature 'std'
    must propagate to:
      parity-scale-codec
Found 55 issues (run with --fix to fix).
Error: Command 'lint propagate-feature' failed with exit code 1

Polkadot-SDK uses the Zepter CLI to detect abnormalities in the feature configuration.
It looks like one more more checks failed; please check the console output. You can try to automatically address them by running `zepter`.
Otherwise please ask directly in the Merge Request, GitHub Discussions or on Matrix Chat, thank you.

For more information, see:
  - https://github.com/paritytech/polkadot-sdk/issues/1831
  - https://github.com/ggwpez/zepter

TODO:

•  Check that CI fails correctly

[bkontur]

Maybe unrelated question, but should dev-dependencies be added to std / try-runtime / runtime-benchmarks features?

E.g. here https://github.com/paritytech/polkadot-sdk/pull/1801/files#diff-57e966c3ef58bb810065f964f9d2d0c5ef141de756082abd9b0f877de98f78c3R25-L34
pallet-balances = { path = "../balances" } and it was unnecessary added to std as pallet-balances/std.
But on the other hand, pallet-balances has to be added to try-runtime as pallet-balances/try-runtime, is that ok?

[ggwpez]

Maybe unrelated question, but should dev-dependencies be added to std / try-runtime / runtime-benchmarks features?

I am not really sure how to handle dev and build dependencies. Normally we dont disable the default features for dev dependencies, so we dont need to add them to std. But for runtime-benchmarks and try-runtime it would make sense.

[liamaharon]

🎉

[ggwpez]

IIUC #1870 moved some deps upstream. Now the problem is that the introduced dependency sp-bls12-381 pulls in sp-crypto-ec-utils from the SDK, which in term wants sp-std v11.
Since we did not backport the version bumps, the repo has version 8 and now pulls that stuff in twice - resulting in a build error here in the CI.

[bkchr]

Does cargo unify deps which have a path and a version? So, would that be really fixed by merging the version bumps back to master?

[ggwpez]

Does cargo unify deps which have a path and a version? So, would that be really fixed by merging the version bumps back to master?

It does not seem to quite fix it, since we use one GH dependency here which then pulls in duplicate versions again.
I locally removed that dep and it worked, so hopefully it would be fixed if the bandersnatch also uses all the latest versions and gets published.