rpc: define spec for RPC

[tac0turtle]

Description

This PR decribes the RPC layer of tendermint. For now this takes what is present on the Go implementation and calls it the canonical implementation. After this is merged we will be able to reduce or expand the spec and anything outside the spec is an implementation detail.

closes #273

this spec does not contain:

• tx_search
• block_search
• dump_consensus_state
• consensus_state
• broadcast_tx_commit
• dial_seeds
• dial_peers

Many of these routes are implementation specific and my not be shared across implementations.

[cmwaters]

I know this is still a draft. But looking good so far.

A couple of extra points:

1. I think this could also be a good area to define the standard Tendermint RPC errors
2. We don't fully comply with the JSON RPC2.0 spec right? Here might be a good place to outline where exactly we diverge

[tac0turtle]

1. I think this could also be a good area to define the standard Tendermint RPC errors

Agree here, should this be a separate PR?

2. We don't fully comply with the JSON RPC2.0 spec right? Here might be a good place to outline where exactly we diverge

Instead of trying to define what we support of JSON RPC 2.0 and what we don't. I would like to say the spec is JSON RPC 2.0 compliant and Tendermint-Go is not adhering to the spec. This will get the Tendermint team to become spec compliant at the RPC layer. This is still up for debate, but this aligns with the goal of getting the implementation to follow specs instead of veering from the spec in order to make things easier.

[cmwaters]

Agree here, should this be a separate PR?

Sure, up to you

[cmwaters]

I feel like this should be paginated or something. In tendermint-go this has a upper bound of 100 i.e. you can only request the top 100 txs

[tac0turtle]

agree, it would be good to paginate more things.

[cmwaters]

Just a few minor things but otherwise good to go