feat: rpc implementation [part 2/5]

[andreabadesso]

Motivation

The idea of this library is to be used by the wallets or by any client wanting to accept the RPC calls defined in the RPC protocol

Some general notices:

• The RPC design makes mixed use of camelCase and snake_case, we should standardize the params and update the design document, this will be done in the params validation PR (part3), which should be done before we're able to publish this library.
• We should also validate the prompt responses, this will be done in the params validation PR (part3)

Acceptance Criteria

• We should not validate parameters in this PR, it should be done in the part3 PR
• We should have a better error handling mechanism, it should be done in the part3 PR
• The library should be handle the following methods (with a few caveats):
  • htr_getAddress
    • the full_path parameter is not yet implemented, it should be implemented in the part4 PR
  • htr_getBalance
    • addressIndexes is not yet implemented, it should be implemented in the part4 PR
  • htr_getConnectedNetwork
    • This will not return the genesisHash defined in the RPC design as we don't yet have an API to fetch it from the fullnode nor a wallet-lib method to get it. This should be done in a later unplanned PR as it will involve changes in the fullnode as well as the lib.
  • htr_getUtxos
    • The implementation was copied from the headless, including the limitations, i.e. no pagination and potential memory issues when large wallets use this method. I think we can publish an initial version with it as it is, but create an issue to actually solve this as potentially more users will use this RPC (interacting with dApps) than headless users and the problem should be more evident on the mobile wallet with constrained memory.
  • htr_sendNanoContractTx
  • htr_signWithAddress

The following methods will be done in the part4 PR:

• [ ] htr_createToken
• [ ] htr_pushTxHex
• [ ] htr_sendTx

The following method will be done in the part5 PR:

• [ ] htr_getOperationStatus

Checklist

• [X] If you are requesting a merge into master, confirm this code is production-ready and can be included in future releases as soon as it gets merged
• [X] Make sure either the unit tests and/or the QA tests are capable of testing the new features
• [X] Make sure you do not include new dependencies in the project unless strictly necessary and do not include dev-dependencies as production ones. More dependencies increase the possibility of one of them being hijacked and affecting us.