Creation of v1/chain/get_raw_block chain API endpoint

[aaroncox]

This is a feature request which will eliminate a bottleneck that our history solution (Roborovski) starts running into under high load. We imagine it'll be useful for other advanced applications as well, ones specifically that access raw block data.

We propose the addition of a new API endpoint:

v2/chain/get_block or v1/chain/get_raw_block (or some named variant of get_block)

This API endpoint will operate nearly identical to the /v1/chain/get_block API endpoint, except it will:

• Not decode any of the transactions using their ABIs, and instead just return the raw hex data.
• Run in a non-blocking thread, or be threaded as much as possible. (Note: we assume here the blocking nature of the current get_block API call is due to the abi decoding).
• Maintain a similar API response structure to the get_block call.

These changes should offer a much more lightweight solution to retrieving a block and its data vs the current get_block implementation.

---

Side note:

As a more radical approach to solving this problem, we could also suggest making these modifications to the get_block call and deprecating the current behavior of decoding transactions. This makes sense since any historical block retrieved is going to be decoded with the current ABI, and not the ABI that was set historically at that point in time. The current get_block call results can often be invalid because of this. It's best to leave decoding historical blocks to some form of history solution which can reference the appropriate ABI.

However, since this would be a breaking change for many applications, the creation of a new API endpoint as suggested above is likely the safest path. Perhaps in the future the v1/chain/get_block call can be deprecated in favor of this new endpoint.

[spoonincode]

Will track this in leap repo now