Deprecate update_opam_repo.sh

Corresponding MR in tezos/opam-repository: opam-repository!500 (merged)

Previous related MRs:

• !12029 (merged) add script to generate the lock file
• !12100 (merged) use the lock file in make build-deps etc.

What

This MR updates the process to update tezos/opam-repository to use the lock file. Instead of using update_opam_repo.sh, we now manually copy the lock file and the opam repository commit hash.

Why

Copying a lock file and a commit hash is arguably simpler that having to update dozens of files in packages/, even though the latter was made simpler with a script that generates a patch. Once Docker image generation is moved from tezos/opam-repository to tezos/tezos, copying the lock file and the commit hash will even be unnecessary, without having to store a whole packages/ directory in tezos/tezos.

This makes the lock file + commit hash the unique source of truth regarding dependencies, although for now this unique source is duplicated (:p).

How

The bulk of the work is in the corresponding MR in tezos/opam-repository: opam-repository!500 (merged) which makes Docker image generation start not from an opam repository, but from an opam lock file.

This MR:

• updates the documentation to reflect the change in the process;
• modifies update_opam_repo.sh so that it does nothing except tell the user that this is no longer the way to go (so that unaware engineers become aware);
• removes the check that ran update_opam_repo.sh since it is no longer relevant (see below);
• updates the hash of the Docker image to use in the CI so that we get file scripts/version.sh from tezos/opam-repository in the Docker image…
• …so that we can add a check that the variable that contains the commit hash of the public opam repository (ocaml/opam-repository) are in sync.

The check that was removed from update_opam_repo.sh made sure that the resulting opam patch was empty. The corresponding check with the new process would be that the lock file is the same in both repos. But there is no need for such a check, because since !12100 (merged) the first check in opam-check.sh tries to install the lock file and checks that there is nothing to do. If the lock files were different in a semantically-impactful way, there would be something to do and the check would fail.

Manually testing the MR

Check the CI, in particular job misc_opam_check.

Checklist

• Provide automatic testing (see the testing guide).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR