Alcotezt: [lib_shell/test] port to alcotezt

Context

Related to: !6760 (closed) and #4741 (closed).

This MR applies the Alcotezt wrapper on the tests: lib_shell

This wraps the tests in a Tezt compatibility layer. In short, this means that the above tests are now executed through Tezt, enabling an improved UI and automated load balancing. For more info on the Alcotezt rationale, see !6760 (closed).

Practically, this entails that this MR will typically contain:

• Modifications to manifest/main.ml for the tests in question to use the tezt instead of test registration function, and regenerate dune and opam files.
• Extending the compatibility layer tezt/lib_alcotezt
• Modifying the tests in question to better fit Alcotezt

--

I noticed that running the tests in test_node.ml creates a .tmp file that is not clean up. However, this is also happened with the original test. The file seems to come from the p2p layer. I couldn't figure out of to get rid of it.

Manually testing the MR

Locally

Running the test:

dune exec src/lib_shell/test/main.exe -- --info

(passing --info prints individual Alcotest cases executed)

The tests in lib_shell/test no longer register a runtest alias. Instead, a runtezt alias is registered:

dune build @lib_shell/test/runtezt

When registered in manifest with the tezt function, the test modules are automatically linked with the main tezt entrypoint tezt/tests/main.exe. This means that one can also run the tests with (example here for test protocol validator):

alias tezt='dune exec tezt/tests/main.exe --'
tezt --list --file "test protocol validator"

In the CI

As the tests are linked with tezt/tests/main.exe, they run in the CI in the tezt jobs. The GitLab interface offers little to find individual test cases in the set of tezt jobs, but you can download the Tezt records from a pipeline on this MR (e.g. [PIPELINE_ID]) and check that they contain the test in question:

PIPELINE=[PIPELINE_ID] dune exec ./tezt/records/update.exe
cat tezt/records/*.json | jq -c 'map(select(.file=="[TEST_FILE]"))[]'

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