Keep walletpassphrase until the next api call it's used in #3714

This patch will allow -1 to be passed to walletpassphrase as the timeout. A timeout of -1 will hold the passphrase in memory until the next api call is made that requires it.

Example:

$ bitcoind walletpassphrase hunter2 -1
$ bitcoind getaccountaddress ''
1M72Sfpbz1BPpXFHz9m3CdqATR44Jvaydd
$ bitcoind signmessage 1M72Sfpbz1BPpXFHz9m3CdqATR44Jvaydd foo
H5UQlcIJjSWbNK/MFaP0LDGt8CSkbe9D8FbdGUFHM/hAQ0avEchg2sJ8v2db8ynOD2PqQwYuR/5tbbKl7LiMUEE=
$ bitcoind signmessage 1M72Sfpbz1BPpXFHz9m3CdqATR44Jvaydd foo
error: {"code":-13,"message":"Error: Please enter the wallet passphrase with walletpassphrase first."}

I realize something similar is doable with:

$ bitcoind walletpassphrase hunter2 60
$ bitcoind signmessage 1M72Sfpbz1BPpXFHz9m3CdqATR44Jvaydd foo
H5UQlcIJjSWbNK/MFaP0LDGt8CSkbe9D8FbdGUFHM/hAQ0avEchg2sJ8v2db8ynOD2PqQwYuR/5tbbKl7LiMUEE=
$ bitcoind walletlock

The former just seems like it might be more convenient for some situations.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/cb31ac84e50f6ae99033c8de5de540345b434eb0 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

NACK. This introduces a statefulness that wouldn't work together with concurrent use of the API:

For example if we have two client, A and B.

A> walletpassphrase hunter2 -1
B> walletpassphrase hunter2 -1
A> sendtoaddress ...
B> sendtoaddress ...
error: {"code":-13,"...")

Suggestion: This might be more reasonable if it only worked with a batch request...

@laanwj - can it be implemented such that the wallet is only unlocked per client?

@rebroad I've also though about it but that's not possible. JSON RPC (as it is now) is stateless. A future RPC protocol with persistent connections could (probably: should) have wallet-decryption-state per client.

NACK. This introduces a statefulness that wouldn't work together with concurrent use of the API: @laanwj, you're right. I didn't even think of that. I was shortsightedly focused on solo commandline use. For now, I figure this can still be useful in situations where an assumption like this can be made though.

For solo command-line use you could make a script that wraps bitcoin-cli and does a walletlock immediately after every command. No need to make server-side changes.