Preliminary support for local keys

[dtebbs]

• use eth-private-key if present to locally sign the tx (as well as eth-address as before)
• test commands/gen_eth_address.py generates eth-private-key and eth-address in the current dir
• test_commands/fund_eth_address.py funds the address, (assumes an the address is unlocked, funds from web3.eth.accounts[0] unless told otherwise) assuming gnache / geth with hosted accounts.
• test scripts (e.g. scripts/test_zeth_cli call setup_user in scripts/test_zeth_client_common.sh to extract a (funded) hosted address from the RPC host. Create two setup functions setup_user_local_key (userd for alice, bob, charlie in the test script) and setup_user_hosted_key (used for deployer in the test scripts)
• Make deploy command also support eth-private-key
• [LOW PRIORITY] Make get_balances in the test scripts (scripts/test_zeth_client_common.sh) use the correct addresses
• Deployment of test token, and token approval using local private keys

[AntoineRondelet]

Here's a quick one even if still WIP

[AntoineRondelet]

@dtebbs there's a box that isn't ticked yet in your PR description. Do I need to treat this PR as still WIP or did you forget to tick the box?

[dtebbs]

@dtebbs there's a box that isn't ticked yet in your PR description. Do I need to treat this PR as still WIP or did you forget to tick the box?

@AntoineRondelet Sorry - I forgot to update it. Good catch.
The functionality was added, so should be good to go. Thanks.

[AntoineRondelet]

Wouldn't it be possible to stick to one type of values here? I mean: do we really need the 3 potential value types?
I find it confusing to see that a flag can take 3 type of values (a URL or a "name" or a file).

[dtebbs]

I definitely get the point. I'm sure it can be improved with more time invested, but my thinking was that each of these forms is a potential use-case, and there should not really be any ambiguity when specifying this. I considered having multiple flags to cover different types, but that would involve quite a bit more complexity and logic to resolve some ambiguous cases like multiple flags being given, overriding each other and falling though to defaults, etc.

So this seemed like a simple solution that avoids ambiguity, but definitely happy to iterate if there is a better way to expose the same functionality.

[AntoineRondelet]

I see, I'll open a ticket to keep this in mind and polish this going forward.

[AntoineRondelet]

Opened #249 to track this

[dtebbs]

(pushed a small fix for the client syncing code, but no other changes planned now)