Use the lock file instead of tezos/opam-repository

This MR is based on !12029 (merged); the first two commits are from !12029 (merged).

What

This MR:

• inlines install_build_deps.raw.sh;
• modify scripts to use octez-deps.opam.locked instead of octez-deps.opam;
• makes make build-{dev-,}deps fetch dependencies from the public opam repository instead of tezos/opam-repository;
• updates the documentation about how to update dependencies (now one needs to update the lock file before running update_opam_repo.sh).

Why

Inlining the small script install_build_deps.raw.sh makes the main script easier to follow, in particular to review this MR. It may have been useful to have it separate in the past, but now that one can just run opam install --deps-only opam/virtual/octez-deps.opam.locked, I don't see a good reason.

Using octez-deps.opam.locked instead of octez-deps.opam in scripts allows to transfer the role of fixing our dependency versions from tezos/opam-repository to this lock file. In particular this allows to update specific dependencies instead of all of them, which is much safer for release branches (i.e. minor releases) and last-minute major releases. It also allows developers to update specific dependencies that they need in their MRs, without asking the reviewers to review all other dependency changes that would be obtained by upgrading the world. (It does mean that we'll need to remember to upgrade the world from time to time, though.)

Fetching dependencies from the public opam repository means that tezos/opam-repository no longer needs to be an opam repository, it can focus on generating Docker images for the CI.

How

After replacing octez-deps.opam with octez-deps.opam.locked in scripts, everything behaves the same as long as tezos/opam-repository provides those exact versions, which it now should since update_opam_repo.sh is one of the script which was updated to use the lock file. In fact, update_opam_repo.sh generates an empty patch, showing that the lock file contains a subset of tezos/opam-repository, which thus does not need to be updated.

To keep the property that we know exactly what is the contents of .opam files that we depend on, the make build-deps script asks opam to fetch a specific commit (full_opam_repository_tag) of the public opam repository.

After this change, tezos/opam-repository is not used by users. It is only used:

• by devs, but only when running update_opam_repo.sh to update tezos/opam-repository following a change in the lock file;
• by the CI, which uses its Docker images (which, in a future MR, we can generate from the lock file).

This should not change the workflow of users; they still run make build-deps.

The workflow of devs changes a bit:

• they still run make build-dev-deps;
• to add/upgrade/remove dependencies:
  • they now have to update the lock file, either manually or by using scripts/update_lock_file.sh;
  • they still run scripts/update_opam_repo.sh and apply the patch to tezos/opam-repository.

Manually testing the MR

What I did was run the following scripts in various orders:

make build-deps
make build-dev-deps
scripts/update_opam_lock.sh
scripts/update_opam_repo.sh

I also did that after changing full_opam_repository_tag to see what will happen when we want to use a more recent version of the public opam repository.

You also want to test the build of debian-deps-build.Dockerfile; I did not, yet, but I think the CI can test it for us?

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• 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