Document all RPC methods

[Sarah-NEAR]

Document all RPC methods (issue)

JSON RPC exposes some endpoints that are not documented in the docs or anywhere else. So we need to identify the importance of each and consider implementing them, or decide to not implement them.

Here’s the list:

Method	What we know about it	To implement or not to implement
health	Too related to the node and the structure of the response is really nearcore-node specific. We just cannod mimicrate the method and avoid confusion	Return error ❌I suggest we return a meaningful error suggesting a requester to point their request to a specific nearcore-node
light_client_proof	@bowen Wang thinks it should be implemented. We did a proxy call	proxy ✅
next_light_client_block	@bowen Wang thinks it should be implemented. We did a proxy call	proxy ✅
tier1_network_info	@bowen Wang thinks it should be implemented. We attempted to do a proxy but near-jsonrpc-client doesn’t support this method either, so we had to postpone it	proxy ❌ https://pagodaplatform.atlassian.net/browse/DPLT-910
client_config	This method requires the Client and I don’t think we can simply proxy it	Return error ❌I suggest we return a meaningful error suggesting a requester to point their request to a specific nearcore-node
EXPERIMENTAL_broadcast_tx_sync	This method has the same signature as broadcast_tx_commit so we can proxy it easily	PROXY ❌
EXPERIMENTAL_check_tx	This method should be proxied	PROXY ❌
EXPERIMENTAL_light_client_proof	:question_mark: It looks like this method gets ExecutionOutcome’s proof by EO id, adds proof from the block and returns it. This might be implemented on our end without a proxy, need a clarification	IMPLEMENT ❌
EXPERIMENTAL_validators_ordered	@bowen Wang thinks it should be implemented. We did a proxy call	proxy ✅
EXPERIMENTAL_maintenance_windows	According to the docstringReturns the future windows for maintenance in current epoch for the specified accountIn the maintenance windows, the node will not be block producer or chunk producerIt is too related to the nearcore-node to be proxied	Return Error ❌I suggest we return a meaningful error suggesting a requester to point their request to a specific nearcore-node
EXPERIMENTAL_split_storage_info	Polina provided details (see below). Seems like too close to the node.Returns DBKind of hot storage, block head, final block head, and head of cold DB. DBKind can be used to determine the type of storage. RPC means that non-archival db, Archival means legacy archival (1 big db), Hot means split storage archival (node has 2 dbs: hot and cold).	PROXY ❌

The list above should be groomed and finished up, also we need to create corresponding tasks as subtasks

[telezhnaya]

FYI we decided not to move forward with this task, it's not required for Read RPC with the new goals that we keep in mind.
Covering unpopular methods is not our priority right now (all undocumented methods are rarely used).