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 #272
  • /json_rpc: cuprated: RPC handlers (json-rpc) #308
  • Other JSON
  • Binary
• Binary string handling
  • monerod proposal: [Proposal] Deprecate RPC binary strings monero-project/monero#9422
  • Cuprate implementation
• Doc-tests
  • Binary request/response data
  • Binary types
  • Mixed types
• Documentation
  • Architecture book: book/architecture: RPC handlers and related #341
  • cuprated RPC docs

Related

• Tracking Issue for RPC interface #183
• Different RPC behavior between cuprated and monerod #278
• Internal data needed for cuprated's RPC #279

TODO

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