RPC stuff that needs to be written in the architecture book:

## General
- diagram showing full pipeline from input to output with crate responsibilities listed along the line

## The handler
- {json-rpc, binary, other} handler functions implemented in `cuprated` <CODE_LINK>
- handler -> helper function -> internal component's `Service`

## Unsupported RPC calls / RPC calls with different behavior
- https://github.com/Cuprate/cuprate/issues/278
- binary strings -> full JSON: `get_transaction_pool_backlog`, `get_output_distribution`
- not in `monerod` yet: `get_tx_ids_loose`

## Differences with monerod (Request strictness)
Some of `monerod`'s RPC request types contain fields not for users to provide,
but for internal usage within the RPC handlers and `monerod` itself, some examples:
- <LINK_TO_INTERNAL_FIELDS_IN_REQUEST_TYPE>

Unless one of these actually allows something unintentionally bad to happen, this is mostly an unimportant detail.
<CHECK_THAT_ONE_OF_THESE_FIELDS_ISNT_A_SECURITY_FLAW>

Practically, it means users can provide these fields and `monerod` will deserialize them
and accept them fine, while `cuprated` will not because they are not part of the type.