update octez-baker dependencies and remove octez-dal-zcash params

What

This MR focuses on debian packaging.

these are two changes we plan for the next release for octez-baker:

• The baker packages will recommend (previously a suggest ) the octez-dal-node. By default, each baker will run the dal node as attester and the configuration of the baker will be changed accordingly. Bakers that are not interested will have the possibility to opt-out and do not run the dal node ( and upgrading the package using --no-recommends
• The dal node package will not include the zcash params data anymore ( the zcash package data for the dal is going to disappear ) as now the octez-dal-node is able to download the zcash params from the network when run in operator or observer mode ( that is not the default ).

consequences:

• on fresh install, by default a baker will install the octez-node, the octez-baker and the octez-dal-node ( on the same machine ) all together. The dal node in attester mode does not consume many resources, so this should be painless. The user will be asked if he wants to run also the dal node
• on upgrade, the octez-dal-node will be installed by default and the user will be asked if he wants to run the dal node as well
• users that do not want to run ( and install ) the dal node must specify --no-recommends on the command line.

This MR implements these modifications.

Why

How

I remove the octez-dal-node-zcash-param and update the dependencies of the octez-dal-node. I also modify the upgrade and install script to add the -with-dal parameters. I add two debconf templates to ask the user its preferences.

Manually testing the MR

Here are the important aspects to consider while testing this MR, with spelling fixed and text clarified:

• Does it compile locally?
• Can it be installed locally?
• Can the octez-node and a baker be run locally using systemd?
• Does the package correctly upgrade from an already installed package?
• Does the package compile in a Docker container?
• Do all CI checks pass?
• Is the installation process user-friendly with clear questions and a good UX?
• Can the package be easily migrated from a Serokell Debian package?
• Does the MR introduce any regressions in lintian?

It's important to note that the CI cannot check all possible use cases, particularly the interactive installation process. Therefore, it's crucial for the reviewer to manually check in a Docker container or VM if the package can be installed interactively and configured as a working Octez service using systemd.

While the MR creator has already performed these manual steps, it's important for the reviewer to independently repeat these tests. For reference, reviewers should consult the following resources:

• Best practices: https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html
• Lintian tags: https://web.mit.edu/~mkgray/stuff/ath/project/silk/root/afs/sipb/project/debathena/lintian/www/tags-all.html
• Debian policy: https://www.debian.org/doc/debian-policy/

Local testing:

To test Debian packages locally, you need a Debian machine with the following packages installed:

• dpkg-buildpackage
• lintian
• debconf-utils

Use the script scripts/packaging/build-deb-local.sh to build Debian packages locally. It accepts two arguments: binaries and zcash to compile all binary packages and all data packages, respectively. Use the --dev flag to run lintian.

While testing the packages locally you should also test for lintian and make sure we didn't introduce any regressions.

CI packages testing

To test packages produced in the CI, refer to the official documentation: Tezos CI Documentation

The CI creates an apt repository for each MR. Replace $CI_COMMIT_REF_NAME with the ref name related to this MR.

For distributions other than debian/bookworm, run a scheduled pipeline to generate packages for this MR using:

pipeline-profiler/run_pipeline_type.sh schedule_extended_test

Then, to test the packages related to this MR you can simply export the env variables as :

    export distribution=next/$CI_COMMIT_REF_NAME/debian
    export release=bookworm

and the follow all the steps in the detailed section dedicated to the installation of the debian packages: https://tezos.gitlab.io/introduction/services.html

We also have a dedicated page for the migration from the Serokell packages that should be considered : https://tezos.gitlab.io/introduction/serokell.html

Test debian packages in isolation

To test Debian packages in a clean environment using Docker, install Docker (Docker Installation Guide https://docs.docker.com/engine/install/#supported-platforms ) and use the following Dockerfile:

FROM debian:bookworm

ARG CI_COMMIT_REF_NAME

RUN apt-get update && apt-get install -y gpg curl

RUN curl https://tezos-linux-repo.storage.googleapis.com/next/debian/octez.asc | gpg --dearmor -o /etc/apt/keyrings/octez.gpg

RUN echo "deb [signed-by=/etc/apt/keyrings/octez.gpg] https://tezos-linux-repo.storage.googleapis.com/next/${CI_COMMIT_REF_NAME}/debian bookworm main" > /etc/apt/sources.list.d/octez.list

RUN apt-get update
RUN apt-get install -y octez-node

You can build the Dockerfile using the command

docker build -f Dockerfile.test --build-arg CI_COMMIT_REF_NAME=< the ref name of this MR> .

NEW

you can also run this command to run the installation tests locally:

DISTRIBUTION=debian RELEASE=bookworm scripts/packaging/tests/systemd-docker-test.sh docs/introduction/install-bin-deb.sh images/packages/debian-systemd-tests.Dockerfile

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