Draft: Build: opam-repository now uses a .opam.locked file

Context

This MR requires opam-repository!382 (closed).

Currently, tezos/opam-repository plays two roles:

• it is a subset of ocaml/opam-repository, with only one version of our external dependencies;
• it builds Docker images where external dependencies are already built, so that the CI of tezos/tezos can use them.

With this MR we completely remove the first role: tezos/opam-repository will continue building Docker images, but it will no longer be a smaller opam repository. We replace this with the use of an opam lock file.

How It Works

We commit an opam lock file in two places:

• in tezos/tezos at opam/virtual/octez-deps.opam.locked (next to opam/virtual/octez-deps.opam);
• in tezos/opam-repository at the root.

Those two files are equal. In the CI, opam-check.sh checks that they are equivalent because if they weren't, opam would not say Nothing to do.

This lock file is generated manually using opam lock. This MR updates the documentation to explain how to do that. Basically, instead of using update_opam_repo.sh, one will now make two MRs to update the lock file. (Script update_opam_repo.sh still exists to ease the transition but it doesn't do much anymore.)

The lock file in tezos/tezos is used by make build-deps, which no longer adds tezos/opam-repository as an opam remote, and no longer removes the default opam remote. Instead, the guarantee that the set of packages is exactly what we want is given by the lock file.

The lock file in tezos/opam-repository is used to know which packages to build into Docker images.

Manually testing the MR

Check that the CI passes (it uses the Docker images generated from the lock file).

Check that make build-deps and make build-dev-deps still work.

It's possible that you still have tezos/opam-repository as an opam remote. You can remove it with:

opam remo{t,v}e tezos --all

You can then test again that make build-deps and make build-dev-deps still work.

Checklist

• 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