Add Cargo Task to generate Deb packages

[morosanmihail]

This creates a Kraken Task that allows users to generate Debian packages from a Cargo project.

These packages can then be published as needed, most likely to apt repositories.

[ntrinquier]

It is a bit annoying because the task may not always be called cargoBuildRelease, it can also be cargoBuildDebug: https://github.com/kraken-build/kraken-build/blob/3011038a7b8c671c606c7c9f97e6b71771914a1c/kraken-std/src/kraken/std/cargo/__init__.py#L291-L292

Perhaps the cleaner solution here is to have CargoGenerateDebPackage accept a list of package_names which can be list[str] | list[Property[BinaryArtifact]].

Then, when calling cargo_generate_deb_package, you'd pass it the path to the binaries or libs coming from the build task:

https://github.com/kraken-build/kraken-build/blob/3011038a7b8c671c606c7c9f97e6b71771914a1c/kraken-std/src/kraken/std/cargo/tasks/cargo_build_task.py#L45-L49

Because if a task has a property which is another task's output property, kraken automatically creates a dependency between the two.

[morosanmihail]

I think this should be fine, as we only want to package release binaries for now. It could definitely be improved in the longer run.

[ntrinquier]

Still, we cannot leave it as is because sometimes the build task will not exist: for example, it might be cargoBuildRelease on develop, and cargoBuildDebug on a feature branch, in which case this will fail.

If we don't want to automatically generate the dependency via Propertys, then we should defer to the caller (who will know better) the responsibility of adding the dependency

[morosanmihail]

Wouldn't we want this to fail if someone has defined it, but there's no build? The only way to use this is manual, for now.

[ntrinquier]

Unfortunately, it is not the task that would fail, but the generation of the task graph. Meaning that you would not be able to run any kraken task, as building the dependency graph would fail with an error (something like No task matched the selector ':**:cargoBuildRelease')

[morosanmihail]

Just checked and I think I can safely remove the dependency on any cargoBuild*. cargo deb seems to build an optimised binary even if cargo build wasn't run first, so it will work in any situation.

And it being part of the publish group should limit repeating work.