manage proxied vault account per shard

[brenzi]

closes #1253
closes #1466

Register a shard vault account on Integritee parentchain (no multichain option yet for this) and register every new shard worker as a proxy

Also added draft doc diagrams on the way that helped me find my way

• derive vault account from enclave seed and shard identifier
• endow vault account as primary worker
• add self as proxy
• persist vault AccountId in state (hardcoded key)
• dummy unshield proxy(balance.transfer_keep_alive) extrinsic (no matter if fails, but must decode correctly)
• register new validateers as proxy upon provisioning
• let stf make use of proxied vault account (example for later unshielding refactoring)

testing

run node:

./target/release/integritee-node --dev --unsafe-ws-external --rpc-cors all

build worker as sidechain
SGX_MODE=SW WORKER_MODE=sidechain WORKER_FEATURES=dcap make

run first worker

export RUST_LOG=info,substrate_api_client=warn,ws=warn,mio=warn,its_consensus_common=info,sidechain=info,integritee_service=trace,enclave_runtime=trace,ac_node_api=warn,sp_io=warn,itc_parentchain_indirect_calls_executor=trace,itp_stf_executor=trace,itc_parentchain_light_client=trace,itc_parentchain_block_importer=trace,itp_stf_state_handler=trace,ita_stf=trace,itp-attestation-handler=debug
./integritee-service -u ws://172.17.0.1 -c -d /tmp/worker1 run --skip-ra --dev &> worker1.log 

verify the following events are issued:

1. teerex.AddedSgxEnclave
2. balances.Endowed creating the vault account
3. proxy.ProxyAdded registering enclave signer as a proxy of vault

You'll also see plenty of enclaveBridge.ProcessedParentchainBlock and sidechain.FinalizedSidechainBlock. don't care!

now, run second worker provisioning

./integritee-service -u ws://172.17.0.1 -r 3444 -P 2100 -h 2110 -w 2101 -i 8788 -c -d /tmp/worker2 request-state --skip-ra &> worker2.log

verify the following events are issued:

1. proxy.ProxyAdded adding the second worker enclave account as a proxy for vault

then, test unshielding (replace mrenclave with yours)

export MRENCLAVE=G51nYibsmo8Gj4VJiEsLxoKttZF6xMbQGCRc3GqzTPHf
./integritee-cli -u ws://172.17.0.1 shield-funds //Alice //Alice 20000000000000 $MRENCLAVE

verify the following events are issued:

1. enclaveBridge.ShieldFunds

then unshield:
./integritee-cli -u ws://172.17.0.1 trusted --mrenclave $MRENCLAVE --direct unshield-funds //Alice //Alice 1000000000000

verify the following events are issued:

1. proxy.ProxyExecuted don't care this fails because we're unshielding funds which never went into the vault account. to be solved later safely unshield using balances.transfer on parentchain #1257

[brenzi]

I wasn't aware that our MU RA is insecure for DCAP. Increases the urgency for #1385

[brenzi]

this is currently not used. I wrote it because I tried to derive the MU RA client from the TLS certificate. fell back to passing it as a payload instead. Still, I think this fn might be useful on its own. webpki and rustls hide the issuer all too well behind private fields

[brenzi]

this allows the enclave to send extrinsics using arbitrary signers (closes #1466)

[brenzi]

necessary to wait for vault to be created before trying to send an extrinsic as vault

[clangenb]

Nice, looks good to me in general, only minor stuff!

[clangenb]

LGTM!