test(pkg): cycles in opam repo (ocaml#8823)

The solver does not check for cyles. This might lead to an invalid build
plan so something to keep in mind.

We also add a test for a situation where there is a cycle in the repo,
but an alternative valid solution is still available.

In both tests the solver ignores the cycle.

Signed-off-by: Ali Caglayan <alizter@gmail.com>

test/blackbox-tests/test-cases/pkg/opam-package-cycle-with-or.t

@@ -0,0 +1,30 @@
+We test an repository with a package cycle that has an alternative solution which avoids a
+cycle. We have the following packages:
+
+>      a --> b --> c
+
+Now c depends either on a or on a fourth package d. Therefore there is a valid solution
+available that avoids a cycle.
+
+  $ . ./helpers.sh
+  $ mkrepo
+
+  $ mkpkg a <<EOF
+  > depends: [ "b" ]
+  > EOF
+  $ mkpkg b <<EOF
+  > depends: [ "c" ]
+  > EOF
+  $ mkpkg c <<EOF
+  > depends: [ "a" | "d" ]
+  > EOF
+  $ mkpkg d
+
+Solver finds the invalid solution as it doesn't check cycles.
+
+  $ solve c
+  Solution for dune.lock:
+  a.0.0.1
+  b.0.0.1
+  c.0.0.1
+

test/blackbox-tests/test-cases/pkg/opam-package-cycle.t

@@ -0,0 +1,35 @@
+Testing how the solver handles cycles in an opam repository.
+
+  $ . ./helpers.sh
+  $ mkrepo
+
+  $ mkpkg a <<'EOF'
+  > depends: [ "b" ]
+  > EOF
+  $ mkpkg b <<'EOF'
+  > depends: [ "c" ]
+  > EOF
+  $ mkpkg c <<'EOF'
+  > depends: [ "a" ]
+  > EOF
+
+Solver doesn't complain about cycles.
+
+  $ solve a
+  Solution for dune.lock:
+  a.0.0.1
+  b.0.0.1
+  c.0.0.1
+
+  $ solve b
+  Solution for dune.lock:
+  a.0.0.1
+  b.0.0.1
+  c.0.0.1
+
+  $ solve c
+  Solution for dune.lock:
+  a.0.0.1
+  b.0.0.1
+  c.0.0.1
+