In/Out_channel Lin test revision

[jmid]

This PR makes a few adjustments to the In/Out_channel Lin tests

• it adds bindings requiring bytes which is now available
• it increases the Lin Out_channel test count, as this is sometimes causing a CI red light with a failure to trigger
• it renames the lin_tests_dsl_common_io library to lin_tests_spec_io to avoid a library/module-name mismatch (minor nit, admittedly)

To understand the Out_channel failure to trigger, I ran some local (Linux) stats.
Interestingly, an In_channel parallel issue is much easier to trigger than an Out_channel one:

  In_channel Domain 101 / 10000       
  Out_channel Domain 0 / 10000

These don't use Util.repeat though. Doing so with Util.repeat 50 (the default) brings the former up to 584 / 10000.
The latter is still crunching away after a couple of hours... 😬

Overall, this motivates the need for a higher test count and the occasional failures-to-trigger that we have observed.

[jmid]

Ha! So as much as these stats are handy for determining slim error rates up front, they clearly lack in assessing times to shrink a found counterexample! (We could calculate stats for that too I suppose).

CI summary of b8cc4bf:

• 3 runs timed out due to long Lin In_channel shrink runs:
  • 32-bit 5.1: 12260secs
  • Windows bytecode 5.1: 9105secs
  • macOS 5.1 9127.9secs
• 3 time outs due to threadomain locks on Windows bytecode 5.1 and trunk 5.2 twice [ocaml5-issue] Windows failures on threadomain #203
• 1 Cygwin 5.1 and trunk (5.2) part 1 time outs due to general slowness (Lin Atomic, Lin Bytes, ...)
• 1 Cygwin trunk 5.2 part 2 time out on a 10764sec Lin ref int64 test with Thread shrink run Improve reproducibility of Lin/STM Thread modes #338
• Linux s390x timed out with several tests taking 1000secs (due to load on the machine I suppose)

The former is news!
I strongly suspect this is caused by Lin fighting to shrink long strings underlying the bytes combinator.

[jmid]

041c177 switches the bytes to use bytes_small akin to what we already do for string.

Locally, I'm observing runs of Lin Out_channel with an unusual execution profile:
Long runs up until finding a counterexample and high GC activity revealed by perf top (top-2):

  48.41%  lin_tests_dsl_domain.exe                       [.] pool_sweep
  14.37%  lin_tests_dsl_domain.exe                       [.] do_some_marking
  ...

I'm curious to see whether this behaviour shows up on the CI too.

[jmid]

CI summary for 041c177:

• 1 bytecode trunk 5.2 timeout during a 10218.4sec Lin DSL In_channel test with Domain shrink run
• on Windows bytecode trunk 5.2 an unexpected counterexample was found for Lin CList int test with Thread Lin.Internal Thread int CList test finds unexpected counterexample under bytecode #358
• 2 Windows bytecode timeouts on 5.1 and trunk/5.2 during a threadomain lock [ocaml5-issue] Windows failures on threadomain #203
• 1 Cygwin 5.1 part 1 timeout dominated by a 9747.3sec Lin ref int64 test with Thread
• 1 macOS arm64 5.0 triggered an unexpected STM Sys test parallel counterexample
• 1 Linux s390x 5.2 interrupted with Disconnected: Switch turned off

The first one is related to this PR and indicated outstanding issues with the In_channel Lin test.

[jmid]

Rebased on main with 5.1.0~beta1 CI tests.

[jmid]

CI summary:

• macOS 5.1 (PR) failed to trigger both STM {int,int64} ref test parallel asymmetric 'STM _ ref test parallel asymmetric' failure to trigger #364
• macOS 5.1 (push) failed to trigger STM int64 ref test parallel asymmetric 'STM _ ref test parallel asymmetric' failure to trigger #364
• Cygwin 5.1 part1 timeout due to slowness: 1074.8s Domain.spawn/join - atomic 1694.6s domain_spawntree - with Atomic 1641.3s Lin DSL Atomic test with Domain 1448.7s Lin DSL Bigarray.Array1 (of ints) test with Domain 2042.7s Lin DSL Bytes test with Domain 1593.9s Lin DSL Bytes test with Thread 1118.7s Lin DSL Out_channel test with Domain
• Cygwin 5.1 part2 timeout during a 11417.6s Lin ref int64 test with Thread shrinking run Improve reproducibility of Lin/STM Thread modes #338

I'll merge as this PR

• increases reproducibility of the Out_channel test
• increases the covered surface by including bytes functions

We can then address excessive Lin DSL In_channel test with Domain shrinking runs separately.