Switch STM_domain.agree_prop_par_asym to use Atomics

[jmid]

I just got around to running a bit of statistics on STM_domain.agree_prop_par_asym for the ref int test.

Switching to use Atomic looks like a clear win when testing locally.
Over 10000 runs this represents a provable improvement at 95% confidence both when compiling to byte code:

$ dune exec src/statistics/z_test.exe 10000 317 10000 786
z-test of two proportions         
z = -14.527927
Is |z| = |-14.527927| > z_alpha2 = 1.960000 ?
Yes, null hypothesis rejected

and when compiling to native code:

$ dune exec src/statistics/z_test.exe 10000 785 10000 1879
z-test of two proportions         
z = -22.766211
Is |z| = |-22.766211| > z_alpha2 = 1.960000 ?
Yes, null hypothesis rejected

In both cases, the number of failed properties doubled!
Interestingly, native code is significantly better at causing trouble than bytecode.

Hopefully this should take care of #364

[jmid]

Whereas the stats are true for Linux, they don't hold up on macOS:

• a macOS trunk 5.2 run fails to trigger STM int64 ref test parallel asymmetric in 2000 iterations

Other CI results include

• Windows trunk 5.2 failed to trigger a parallel Lin Out_channel issue Reliability of parallel Lin Out_channel tests #360
• Cygwin part 1 trunk 5.2 timed out with domain_spawntree, Lin Atomic, Lin Bytes spending +1600secs each
• Windows bytecode trunk 5.2 hit a threadomain lock [ocaml5-issue] Windows failures on threadomain #203

[jmid]

I ran some stats on my old macBook yesterday:

• with the existing Semaphore.Binary (2-3 runs with 10000 iterations)
  - native asym 54/73/59
  - bytecode asym 17/22/31
• with the proposed Atomic bool
  - native asym 71/86
  - bytecode asym 201/170
• with an Atomic int
  - native asym 131/119
  - bytecode asym 260/246

So, an Atomic bool is better than a Semaphore.Binary on macOS with native code:

$ dune exec src/statistics/z_test.exe 30000 186 20000 157
z-test of two proportions         
z = -2.189814
Is |z| = |-2.189814| > z_alpha2 = 1.960000 ?
Yes, null hypothesis rejected

and an Atomic int is better still:

$ dune exec src/statistics/z_test.exe 20000 157 20000 250
z-test of two proportions         
z = -4.633472
Is |z| = |-4.633472| > z_alpha2 = 1.960000 ?
Yes, null hypothesis rejected

And the same holds for under bytecode.

[jmid]

CI summary:

• Windows 5.1, Windows trunk (5.2), and Windows bytecode 5.1 failed with an expired certificate
• Windows bytecode 5.1 triggered a threadomain lock [ocaml5-issue] Windows failures on threadomain #203
• Linux arm64 5.1 and 5.2 both failed to trigger a Lin Out_channel failure Reliability of parallel Lin Out_channel tests #360
• There are still 4 ongoing Cygwin part 2 workflows (these all succeeded)

Overall, this is encouraging as the different kinds of failures are getting fewer - and none of them is an asym failure.

[jmid]

I've added a CHANGES entry in 840a01d as this changes the user-facing STM_domain.agree_prop_par_asym binding for the better.
I've also rerun the lockfree test suite (our primary client) with the result to confirm that it continues to work as expected.
I'll let the new CI run complete over night and then merge tomorrow if things continue to look good.

[jmid]

CI summary:

• 1 Windows trunk 5.2 bytecode failed to trigger STM Weak HashSet test parallel Weak test revisions #365
• 1 Cygwin 5.1 part 1 timeout due to multiple tests taking +1000sec (domain_spawntree, Lin Atomic, Lin Hashtbl, Lin Bytes) Improve reproducibility of Lin/STM Thread modes #338
• 1 Cygwin 5.1 part 2 timeout due to two Thread tests taking +3300sec (STM int64 ref test and Lin ref int64 test)
• 1 Windows 5.1 threadomain lock [ocaml5-issue] Windows failures on threadomain #203

Again, no issues with the adjusted STM_domain.agree_prop_par_asym from this PR show up, so I'll merge.