In addition to being unlocked, wallets now require their password to reveal their private keys.

RPC endpoint changes:
/v1/wallet/get_public_keys -- No change. This endpoint prints all public keys from all unlocked wallets.
/v1/wallet/list_keys -- This endpoint now requires two strings: the name of an unlocked wallet and its password. It will then reveal the public and private key pairs of that wallet. Be aware this means a slight change in behavior in that it is now impossible to query private keys from all unlocked wallets.

cleos changes:
wallet keys -- This command has been changed to print all public keys from unlocked wallets (corresponds to the get_public_keys endpoint). Be aware that there is a change in behavior due to different behavior in how get_public_keys works vs previous behavior: if there is no open wallet or all wallets are locked, wallet keys will now return a "no available wallet" or "locked wallet" error. Previously an empty list would be returned.
wallet private_keys -- This is a new command that maps to the list_keys endpoint. It will take the wallet name and password as arguments before printing the public/private key pairs.

-Fixed issue where wallet required with --skip-sign option (thanks @grock999)
-Fixed check for keosd specified as local before attempting to launch.

chain_id_type should be its own type (without a public default constructor) rather than just a typedef of fc::sha256 #3415

Special exceptions had to be made to `fc::variant::as()const` and
chain_plugin and net_plugin to access the private default constructor.
This is an ugly hack but it works for now. Eventually I need to see if
there is a better solution.

Also the initial public key of the 'eosio' account can now be specified
in CMake rather than specifying the chain ID.

It's common that 'cleos' and 'nodeos' are deployed separately into
different locations and they communicate across a network. In such case,
it's important to let 'cleos' has the ability to include HTTP headers so
that it can go through some 'middle' devices which requires some kind of
'token' included in the requests.

So a new option for 'cleos' in included to provide this ability.

This option is used to disable the verification for the peer certificate
when using HTTPS to the node. Sometimes a typical set up of the EOS node
would not assign a domain name to the node IP address so it's hard to
get legal validation of the certificates, which will lead to a
connection failure...

if a user specifies the unlock-timeout option to the wallet unlock command, cleos runs keosd with --unlock-timeout option

Also added a version and extensions field to abi_def.

Also reduce default_max_transaction_cpu_usage to half of default_max_block_cpu_usage.

update cleos to get account response format (seems like it changed recently), unit-test for delegatebw with transfer, avoid devision by 0 in resource_limits.cpp #3001

This change adds the concept of a wallet being asked to create a new private/public key pair. It is a precursor to hardware key support in the wallet because hardware key stores don’t always have the concept of “importing” a key. It’s also beneficial as it gives an alternative means to `cleos create key` which if not careful can cause a private key to easily weasel its way in to a user’s shell history.

cleos was expecting the old data structure from transaction_trace which changed as part of c1aa8039 EOSIO/eos#2919