add Tezt 4.2.0

[rbardou]

Changelog for the curious: https://gitlab.com/nomadic-labs/tezt/-/blob/master/CHANGES.md

[rbardou]

Tests that fail in the CI fall into the following categories:

• the test-signals test fails for various reasons
  • This test is known to be flaky, I tried to fix it but looks like it was not enough (it fails on architectures on which I didn't test it myself).
• JavaScript issues on specific architectures
  • node:fs missing
  • caml_blit_string_to_bigstring not implemented
  • it's ok to not support JS on those architectures
• timestamp issues
  • printed the wrong way on arm32 (e.g. [16:31:04.-01])
    • so they do not match the regexp to be replaced by a placeholder in cram tests, so they may the tests fail
    • probably an issue with float precision or printf on this architecture?
    • users can probably live with those slightly broken timestamps
  • printed correctly but sed does not replace them with a placeholder anyway on macos-homebrew-ocaml5.2-arm64
    • looks like sed behaves differently on this architecture so the timestamps behave correctly but the test is broken on this architecture
• fixed seed fails with expected x = 3284848139645624427 or 7949467250670036511, got 3999246909259713298
  • looks like the PRNG behaves differently on s390x
  • we had a similar issue last release on more architectures and we fixed it for all of them except this specific architecture, it looks like
  • not a problem for users
• weird compilation errors with OCaml 5.2 on "exotic" architectures
  • arm32-ocaml-5.2 and x86_32-ocaml-5.2
    • dune says "no rule for..." and I don't know why
    • then we see internal worker error: no current child state and this error is basically an assert false
      • basically some reference is set to Some _ just before a function is called, and this function reads the reference value as None
    • overall I don't understand what is happening; this seems specific to OCaml 5.2 on 32bit architectures
  • riscv64-ocaml-5.2: it says compilation failed but there is no compilation error in the logs so I don't know

Overall, the only issues that worry me are compilation errors with OCaml 5.2 on "exotic" architectures. I still suggest to merge. Or do you think we should add some constraints in the opam file to declare the package as not working on those architectures? If so, any suggestion on the syntax?

The good news is that the errors that occurred for the last release have mostly been fixed since then, as promised by me at the time.