move tallyitem struct definition to wallet.{h,cpp} #2071

more RPC abstraction/encapsulation work

I'm very much in favor of encapsulating the actual logic for many RPC methods to where it belongs. However, that doesn't mean that the conversion to JSON should happen there.

For example, if CWallet and CWalletTx had a cleaner interface for requesting information, this could reduce duplication between RPC and GUI. However, that probably means something a thin layer in between of data structure to represent information extracted from and sent to the wallet. The GUI would inspect these structure and convert them to GUI elements, the RPC would inspent them and convert to JSON.

Yeah, I'm going to back out the JSON stuff. My eventual goal for this is to make CWallet a fully-functional first-class object, hide CWalletDB entirely, and have the RPC methods talking strictly to the wallet object. In addition to the "standard" benefits of proper encapsulation, this will eventually allow the client to support, for example, multiple wallets.

@mikegogulski Sounds great, I think that's what we want. Note that there are some plans to move to another database backend for the wallets. Just so you don't waste effort on code that's going to be thrown out anyway.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/82afcf6b0f6b6f286dca8d5444c43997bb602e1b for binaries and test log.

Got it. I think it should be no problem, since the model I'm stumbling toward is like:

consumer(e.g. bitcoind, bitcoin-qt, others)->walletRPCinterface->walletobject->...
->...walletdbobject->nativedbobject
->...blockchainRPCinterface->blockchainobject->whatever

where walletRPCinterface is the one and only interface to the wallet object, nothing but the wallet object talks to the wallet database object, and the wallet interacts with the blockchain strictly via a (new) RPC interface.