Signing transactions with rotating token

[tomusdrw]

1. Introduce new methods to AccountsProvider (sign_with_token)
2. First token = Account password
3. The account is copied to temporary store and encrypted with new randomly-generated token.
4. Next request can use returned token to sign transaction instead of using original password.

TODO:

• Finish implementing RPC method
• Nicer handling of set_name/set_meta updates in EthStore
• Tests for EthStore
• Timeouts for items in transient_sstore (token is valid only for some specified time; logged here: Rotating tokens timeouts #3758 )

[rphmeier]

what will happen here when the account is already present in the transient store?

[tomusdrw]

Transient store supports many entries with the same address, so it will be fine. Actually this is exactly what we want.

[rphmeier]

What's the main use case for this? Will it be exposed over RPC to enable sending TXs in rapid succession more securely? It seems that once an account is in the transient store there are actually two valid "passwords" which could be used to unlock it, doubling the attack surface. Shouldn't it be impossible to unlock an account just using its password until any valid tokens have expired?

[tomusdrw]

This PR already contains RPC methods that could be used for signing with token.
The idea is to unlock account for particular "session" current unlocking stores user's password in memory, other option would be to store password in JS or store unencrypted key in memory. All those feel quite unsafe.
With token we can have many sessions (all start with user password) that use one-time tokens (with good enough entropy) to prove that the request is part of the session. Additionally we use the token to encrypt the private key. So Parity never stores neither password or unencrypted key longer than needed. JS will store the token which cannot be used twice.

[gavofyork]

lots of try!(X)s rather than just X?s...