Optional dependencies

[tomtau]

Not sure if this will be resolved with #387
but could some tendermint-rs dependencies be made optional (with a feature-guard) -- e.g. if one's TM genesis.json is configured with:

    "validator": {
      "pub_key_types": [
        "ed25519"
      ]
    }

It's unnecessary to have signatory with ecdsa-feature, signatory-secp256k1 and ripemd160?

[xla]

This can only work if the genesis information is known at compile time. Alternatively different releases with different features could be evaluated.

[yihuang]

One of the motivation to make signatory-secp256k1 optional: currently secp256k1-sys has dependency cc >=1.0.28, <=1.0.41, and ring has dependency cc ^1.0.52, they are conflicted.
So trying to upgrade to current tendermint-rs master version cause our project to downgrade some dependencies.

EDIT: It seems cargo resolve version not considering feature, so make it feature guarded don't help with this.

[ebuchman]

This can only work if the genesis information is known at compile time

Sure, but we know virtually everyone is only using ed25519, so we should make this optional, and even default off.

[tarcieri]

FYI, I just shipped a pure Rust alternative to secp256k1-sys - the k256 crate (already a dependency of tendermint-rs) now natively supports ECDSA signing and verification:

https://www.reddit.com/r/rust/comments/i7lca3/ann_rustcrypto_k256_and_p256_v020_pure_rust/

It uses a similar implementation strategy (complete projective formulas, constant time scalar multiplication, field arithmetic based on "lazy reductions", optional endomorphism-based optimizations).

[xla]

Do we need to follow-up on @tarcieri announcement @liamsi ?

[tarcieri]

@xla I plan on opening a PR later today which upgrades everything.

It can remove both the signatory-secp256k1 and signatory-dalek dependencies, as the k256 crate now natively implements ECDSA, and ed25519-dalek now natively implements the Signer and Verifier APIs.