Data-encoding: manifestation (inactive)

What

This MR adds data-encoding to the manifest to generate its dune and .opam files.

It does NOT make Octez use it, Octez still uses the external data-encoding.

Why

For data-encoding to be part of Octez, it needs to be handled by the manifest. For instance, with more work it would allow Manifezt to select data-encoding tests. It also allows to check that the .opam files make sense.

This is extracted from !12004 to make it easier to review. The part that makes Octez uses the manifest-ed data-encoding will be done in another MR, so that reviewers can, for now, focus on the manifest-ation.

How

We add manifest targets to make the manifest generate files that are close to what they were before the manifest-ation.

Some parts are not supported by the manifest so they were put in a dune.inc file. An alternative would be to use the pseudo-sexp syntax from the manifest in ~dune directly. I guess @raphael-proust found having an .inc file more readable.

To prevent this manifest-ation from having an impact on opam/virtual/octez-deps.opam, and thus on the lock file, the packages are put in a separate profile, in a separate commit so that it can easily be reverted later. This is why a file opam/virtual/data-encoding.opam is generated. It will be removed when we put data-encoding in the octez profile.

Additionally, a commit removes md2mld, once again to ensure that there is no impact on the lock file. This commit will be reverted once we plug data-encoding into Octez for real.

Manually testing the MR

I suggest reviewers review the changes in dune files carefully.

Some tests that can be done:

# check that the lock file is unaffected
make -C manifest
make -C ci
scripts/update_opam_lock.sh
git diff
# check that it compiles
# (you should remove data-encoding from the data_only_dirs stanza in the root dune file first)
dune build data-encoding
dune runtest data-encoding

Also, you should edit a random file in data-encoding to break it (i.e. insert garbage) and make sure that Octez still compiles, to prove that Octez does not (yet) uses this data-encoding folder but still relies on external packages.

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