Long_tests: Test the non_blocking RPC feature

What

Long tezt to benchmark the "external RPC process" feature.

Why

The test is designed to showcase that the introduction of the external RPC process done in !9490 (merged) achieves its main purpose: it unblocks the progress of a bootstrapping node while being bombarded by heavy RPC calls (like getting all contracts or some particular big maps).

How

In this test, there is a REF_NODE node which will contain enough history for two other nodes (LOCAL_NODE and EXTERNAL_NODE) to be able to bootstrap (or at least be in the process of bootstrapping). The difference between the two nodes is that one of them (LOCAL_NODE) uses the local RPC process, whereas the other one (EXTERNAL_NODE) uses the --external-rpc-addr argument to spawn an external RPC process.

Each node will be bootstrapped against REF_NODE in turn, and after some fixed amount of time (in which the bootstrapping node will be bombarded with RPC calls), we will benchmark how far it got. Currently, that means retrieving its current level.

Manually testing the MR

First, download a bootstrapping snapshot for the two local nodes and then the necessary data-dir for the reference node. I downloaded them both from our Google Drive.

• reference_dir : mainnet_5_610_000-10k_contexts.tar.gz
• bootstrapping_snapshot : TEZOS_MAINNET-BM1kfNJe5674aeF16whjK634Wz5fq6rWKxbSmciVe2CHSnMKSjU-5600000.rolling (level 5600000)

Then, modify the two corresponding variables at the beginning of tezt/logn_tests/non_blocking_rpc.ml. (This needs to be adjusted to be production-ready)

dune exec tezt/manual_tests/main.exe -- --test "Check progress made by node during bootstrapping" --info

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