RPC node tracking a subset of shards

[telezhnaya]

See the discussion here https://near.zulipchat.com/#narrow/stream/295302-general/topic/RPC.20tracking.20subset.20of.20shards https://docs.google.com/document/d/1cYs6erFk2bUiqNxyPR9nWYQETHwzYEDJrRBksHEPW9c/edit?usp=sharing

• [x] https://github.com/near/nearcore/issues/11230
• [ ] Check that we give a meaningful error if the node does not have a needed data
• [ ] Add RPC method returning execution outcome by id
• [ ] Design the solution which helps the user to find out, which RPC node / which shard should they ask to receive the needed data
• [ ] Implement partial responses (should be a new method?) if the request requires multiple shards (e.g. tx with receipts)
• [ ] Implement the solution to create final response from partial responses
• [ ] Check that request forwarding works for applying the transaction to the chain -- this is partially done, several core engineers approved it works fine. I don't want to spend additional effort on this, but it would be nice to see this in action during next Stake Wars IV phase
• [ ] deprecate tracked shards config which gives wrong info which shard is tracked
• [x] Go through all RPC methods and the data we have in RocksDB and check if we need to add new methods or edit the existing ones, keeping in mind that RPC node now may track only a subset of shards

[telezhnaya]

I reviewed existing RPC methods and grouped them into categories:

We can track only 1 shard to provide the answer:

• block
• chunk
• gas_price
• health
• light_client_proof (1 shard is required, I confirmed, looks weird, but it will not work on light client)
• next_light_client_block (should work even on light client tracking 0 shards)
• network_info (should work even on light client tracking 0 shards)
• validators
• client_config
• query:view_access_key
• query:view_access_key_list
• query:view_account
• query:view_code
• query:view_state
• query:function_call (I assume contract view calls are not allowed)
• query:single_access_key_changes
• EXPERIMENTAL_genesis_config
• EXPERIMENTAL_light_client_proof
• EXPERIMENTAL_protocol_config
• EXPERIMENTAL_receipt
• EXPERIMENTAL_validators_ordered
• EXPERIMENTAL_maintenance_windows
• EXPERIMENTAL_split_storage_info

Some of the requests should work fine even with the light client, but the majority of the requests requires a specific shard, and the user doesn't know and doesn't have a way to find which exact shard do they need.

We need all the shards (in the worst case) to provide the answer:

• tx
• EXPERIMENTAL_changes
• EXPERIMENTAL_changes_in_block
• EXPERIMENTAL_tx_status

We are already redirecting these queries:

• broadcast_tx_async
• broadcast_tx_commit
• EXPERIMENTAL_broadcast_tx_sync