upgrade substrate-api-client

[brenzi]

update client to
https://github.com/scs/substrate-api-client/releases/tag/api-M1

we may want to do this first: scs/substrate-api-client#15
and then update to master

[brenzi]

blocked by scs/substrate-api-client#18

[brenzi]

I'm getting ring dependency trouble because of differing versions:

error: failed to select a version for `ring`.
    ... required by package `webpki v0.19.0`
    ... which is depended on by `host_calls v4.0.0 (https://github.com/scs/substraTEE-node?branch=cl-upstream-sync#660961a8)`
    ... which is depended on by `sr-io v2.0.0 (https://github.com/scs/substraTEE-node?branch=cl-upstream-sync#660961a8)`
    ... which is depended on by `sr-primitives v2.0.0 (https://github.com/paritytech/substrate?rev=9b08e7ff938a45dbec7fcdb854063202e2b0cb48#9b08e7ff)`
    ... which is depended on by `sr-staking-primitives v2.0.0 (https://github.com/paritytech/substrate?rev=9b08e7ff938a45dbec7fcdb854063202e2b0cb48#9b08e7ff)`
    ... which is depended on by `srml-babe v2.0.0 (https://github.com/paritytech/substrate?rev=9b08e7ff938a45dbec7fcdb854063202e2b0cb48#9b08e7ff)`
    ... which is depended on by `substratee-node-runtime v4.0.1 (https://github.com/scs/substraTEE-node?branch=cl-upstream-sync#660961a8)`
    ... which is depended on by `substratee_worker_enclave v4.0.0 (/home/abrenzikofer/substraTEE-worker/enclave)`
versions that meet the requirements `^0.14` are: 0.14.6, 0.14.5, 0.14.4, 0.14.3, 0.14.2, 0.14.1, 0.14.0

the package `ring` links to the native library `ring-asm`, but it conflicts with a previous package which links to `ring-asm` as well:
package `ring v0.16.5 (https://github.com/mesalock-linux/ring-sgx?tag=v0.16.5#a95b6198)`
    ... which is depended on by `rustls v0.16.0 (https://github.com/mesalock-linux/rustls?rev=36995713775439e1a60a01cfa327e045a61020a6#36995713)`
    ... which is depended on by `substratee_worker_enclave v4.0.0 (/home/abrenzikofer/substraTEE-worker/enclave)`

failed to select a version for `ring` which could resolve this conflict

I thought this kind of trouble should be solved for recent ring

on branch brenzi-upstream-sync

[brenzi]

aligned rustls versions in host_calls, but I couldn't patch all to use mesalock fork (enclave is a lib and libs can't patch. putting the patch in the workspace breaks libp2p because it rdepends on ring 0.14, not .16)

error: failed to select a version for `ring`.
    ... required by package `webpki v0.21.0`
    ... which is depended on by `host_calls v4.0.0 (https://github.com/scs/substraTEE-node?branch=cl-upstream-sync#90c1680d)`
    ... which is depended on by `sr-io v2.0.0 (https://github.com/scs/substraTEE-node?branch=cl-upstream-sync#90c1680d)`
    ... which is depended on by `sr-primitives v2.0.0 (https://github.com/paritytech/substrate?rev=9b08e7ff938a45dbec7fcdb854063202e2b0cb48#9b08e7ff)`
    ... which is depended on by `sr-staking-primitives v2.0.0 (https://github.com/paritytech/substrate?rev=9b08e7ff938a45dbec7fcdb854063202e2b0cb48#9b08e7ff)`
    ... which is depended on by `srml-babe v2.0.0 (https://github.com/paritytech/substrate?rev=9b08e7ff938a45dbec7fcdb854063202e2b0cb48#9b08e7ff)`
    ... which is depended on by `substratee-node-runtime v4.0.1 (https://github.com/scs/substraTEE-node?branch=cl-upstream-sync#90c1680d)`
    ... which is depended on by `substratee_worker_enclave v4.0.0 (/home/abrenzikofer/substraTEE-worker/enclave)`
versions that meet the requirements `^0.16.0` are: 0.16.9, 0.16.7, 0.16.6, 0.16.5, 0.16.4, 0.16.3, 0.16.2, 0.16.1, 0.16.0

the package `ring` links to the native library `ring-asm`, but it conflicts with a previous package which links to `ring-asm` as well:
package `ring v0.16.5 (https://github.com/mesalock-linux/ring-sgx?tag=v0.16.5#a95b6198)`
    ... which is depended on by `rustls v0.16.0 (https://github.com/mesalock-linux/rustls?rev=36995713775439e1a60a01cfa327e045a61020a6#36995713)`
    ... which is depended on by `host_calls v4.0.0 (https://github.com/scs/substraTEE-node?branch=cl-upstream-sync#90c1680d)`
    ... which is depended on by `sr-io v2.0.0 (https://github.com/scs/substraTEE-node?branch=cl-upstream-sync#90c1680d)`
    ... which is depended on by `sr-primitives v2.0.0 (https://github.com/paritytech/substrate?rev=9b08e7ff938a45dbec7fcdb854063202e2b0cb48#9b08e7ff)`
    ... which is depended on by `sr-staking-primitives v2.0.0 (https://github.com/paritytech/substrate?rev=9b08e7ff938a45dbec7fcdb854063202e2b0cb48#9b08e7ff)`
    ... which is depended on by `srml-babe v2.0.0 (https://github.com/paritytech/substrate?rev=9b08e7ff938a45dbec7fcdb854063202e2b0cb48#9b08e7ff)`
    ... which is depended on by `substratee-node-runtime v4.0.1 (https://github.com/scs/substraTEE-node?branch=cl-upstream-sync#90c1680d)`
    ... which is depended on by `substratee_worker_enclave v4.0.0 (/home/abrenzikofer/substraTEE-worker/enclave)`

failed to select a version for `ring` which could resolve this conflict
a

so even though all are using 0.16 now, cargo doesn't get it

[brenzi]

api-client is now used for extrinsics as of 1228859

currently stuck at no_std issues.

possible blockers:
dalek-cryptography/ed25519-dalek#35

• workaround: try to use rust-crypto::ed25519 again :-(

and because I re-introduced schnorkel (sr25519):
w3f/schnorrkel#31

• workaround: drop sr25519 support. not easy because application-crypto relies on it. Maybe fake it to actually be ed25519?

[brenzi]

resolved with PR #61. including schnorrkel support