Minimal octez-rpc-server that redirects to the node

This MR implements a minimal octez-rpc-server, that is a fork of the node, that aims to forward all the rpcs it receives to the node it issued from.

The changes are completely transparent to the user.

Benchmarking

We are comparing in the following data the performances of two implementations.

• the node (targeted master)
• the node + the rpc server process (this branch)

The running scripts fetches as much blocks as possible, in parallel, within 10sec by calling the RPC chains/main/blocks.

We can observe that the number of blocks fetched of both implementation are close to each other. We deduce that the RPC server behaves with similar levels of performance and that our implementation doesn't introduce any drop in terms of computation time for RPC calls.

on Nairobinet with master:

7792 blocks in 10s (487 calls)
7760 blocks in 10.01s (485 calls)
7760 blocks in 10s (485 calls)
7696 blocks in 10.01s (481 calls)
7584 blocks in 10.01s (474 calls)
7520 blocks in 10.01s (470 calls)
7520 blocks in 10s (470 calls)
7504 blocks in 10s (469 calls)
7456 blocks in 10.01s (466 calls)
7424 blocks in 10.01s (464 calls)

moy 7601, med 7584

on Nairobinet with vicall@octez-rpc-server:

7840 blocks in 10s (490 calls)
7792 blocks in 10.01s (487 calls)
7792 blocks in 10s (487 calls)
7728 blocks in 10.01s (483 calls)
7632 blocks in 10.01s (477 calls)
7616 blocks in 10.01s (476 calls)
7616 blocks in 10.01s (476 calls)
7536 blocks in 10s (471 calls)
7376 blocks in 10.01s (461 calls)
7360 blocks in 10s (460 calls)

moy 7628, med 7632

More data comparison on mainnet (blocks per seconds)

With master:

912 944 800 848 912 848 848 816 704 800 688 784 768 640 784 960 992 864 992 880 816 816 752 672 768 752
mean: 805
median: 816

with vicall@octez-rpc-server:

944 976 880 992 960 912 896 768 800 736 800 816 640 832 864 784 832 896 832 784 816 672 704 720 736
mean: 818
median: 816

Manually testing the MR

Run and us your node as usual. Make sure that all the tests are passing.

To monitor the behavior of this new feature, a node and a baker can be watched here: Nairobi dashboard

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR