Agree on final design spec of new remote functionality for "full node" wallets and block explorers

[idky137]

Several options have been discussed:

• A wrapper around the ReadStateService from Zebra, either hyper or a gRPC implementation. Offering a 1-2-1 correlation of functionality provided by the ReadStateService would provide a tidy way for "cli-wallets" to access chain data either locally or remotely but adds dev time duplicating functionality already offered by the lightwallet gRPC service.

• Extending The lightwallet gRPC service with functionality required by "cli-wallets" and block explorers to provide a single unified API would lead to a more concise and easier to maintain service but would require extra dev by consumers to implement both local and remote functionality. (This could be nullified by adding a set of public methods in Zaino-State with a 1-2-1 correlation with the extended wallet gRPC service.)

[idky137]

A possible gRPC implementation:

• Update the current lightwallet RPC protocol to include:
  • A subset of the current services to be defined in #70 and #71.
  • A new set of services to be defined in #72.
  • A feature gated get_custom_index RPC that exposes ReadStateService functionality to build custom indexes.
• Implement identical pub methods and gRPC services based on this new specification in Zaino-State and Zaino-Serve.

This would allow any wallets or block explorers to have a simple interface to fetch data both locally and remotely and allow for more complex indices to be built when running code privately. But would also stop public Zaino servers that will replace lightwalletd from exposing potentially dangerous functionality.

[arya2]

A simple wrapper for the ReadStateService seems best. Multiple encodings could be supported by tonic as long as there are From and Codec impls for them (though tonic doesn't yet support selecting a codec with the content-type header so it would need to use different endpoints or rust cfg flags).