Tracking Issue for RPC handlers

[hinto-janai]

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter.

What

This is a tracking issue for Cuprate's initial RPC handler implementation. The RPC handlers build upon the previous crates created in #183. They implement the function bodies responsible for mapping requests to responses.

Steps

• Internal changes required for RPC handlers
  • rpc/interface: separate RpcHandler into 3 tower::Services #266
  • cuprated: internal signatures required for RPC #297
  • types: JSON representation types #300
  • cuprated: add constants & statics modules #301
  • types: HardFork improvements #309
  • rpc-types: fix HardForkInfoRequest #310
  • cuprated: internal signatures required for RPC pt. 2 #320
• Handlers
  • Initial skeleton, fn signatures, mappings
    • cuprated: initial RPC module skeleton #262
    • cuprated: RPC handlers (temporary draft) #272
  • Implementation: cuprated: RPC handlers #355
• Documentation
  • Architecture book: book/architecture: RPC handlers and related #341

Related

• Tracking Issue for RPC interface #183
• Different RPC behavior between cuprated and monerod #278
• Internal data needed for cuprated's RPC #279
• rpc/types: fix epee deserialization for GetBlocksResponse #345

TODO

• rpc: start cuprate-rpc-types #147 (comment)
• rpc: start cuprate-rpc-types #147 (comment)
• architecture-book: fill RPC section #243 (comment)