Add support for full recipe loading

[therazix]

This PR implements a full recipe loading feature. All phases can now be loaded directly from the recipe. Serialization and deserialization were replaced with to_spec/from_spec methods, and the generated recipe will now contain only non-empty values to reduce its size.

Resolves: #4531

Pull Request Checklist

• implement the feature
• write the documentation
• extend the test coverage
• update the specification
• adjust plugin docstring
• modify the json schema
• mention the version
• include a release note

[gemini-code-assist]

Code Review

This pull request implements full recipe loading, serializing the complete plan state into a recipe file to enable reproducible runs. A key change involves dynamically deriving the discover-phase attribute from test paths. However, a critical security vulnerability has been identified: the implementation of test path recreation in the discover step is susceptible to Path Traversal. The path attribute from the recipe is used to construct filesystem paths for directory creation without adequate sanitization, potentially allowing an attacker to create directories outside the intended workdir using .. sequences. This requires remediation by validating that the resulting paths do not escape the intended base directory. Additionally, there are a couple of suggestions to improve code robustness and clarity in tmt/recipe.py.

[thrix]

The full recipe loading direction is good. Three findings, one requiring a change:

1. Run.environment silently ignores CLI --environment when recipe is loaded - The recipe env unconditionally overrides CLI options. New --environment overrides on replay are silently lost. This should merge recipe env with CLI env, letting CLI take precedence.

2. link field type mismatch after unserialization removal - Raw data stored where Links object is expected. Not an active runtime bug but incorrect typing that could break on re-serialization paths.

3. Unrelated schema change - display-guest in report/display.yaml should be split out.

[skycastlelily]

Besides other comments, the code appears to assume the recipe file is well-formed, do you consider add some validation to the recipe file provided, say, a schema file?

[happz]

@therazix please, set the "Size" of this PR.

[thrix]

Review: Add support for full recipe loading

Good progress on extending recipe loading from discover-only to all plan steps. The environment simplification and removal of discover_phase are clean.

Issues

Blocking:

• CLI environment silently ignored (tmt/base/core.py): The early return bypasses _environment_from_cli, so --environment FOO=bar is silently dropped when using --recipe. See inline comment for suggested fix.

Latent bug:

• _RecipeTest.link unserialization removed (tmt/recipe.py): Works today because all test links are [] (falsy short-circuit), but would AttributeError on any recipe with non-empty test links. See inline comment.

Hygiene:

• Unrelated schema change (tmt/schemas/report/display.yaml): display-guest addition is not related to recipe loading — should be a separate commit/PR.
• PR checklist: All items are unchecked — docs, spec, schema, version, release note still needed.

Verified non-issues

• Path traversal in discover_from_recipe: The relative_to() + resolve() + parent check is sufficient. The gemini-code-assist security warning is overblown.
• Removed "non-existent plan" test: Correct — with tree.children.clear(), the tree IS the recipe, so the old error case no longer applies.
• Only saving _environment_from_fmf in _RecipePlan: Reasonable — _RecipeRun.environment captures the full merged env, and intrinsics should be regenerated per run.

Generated-by: Claude Code

[thrix]

@therazix would it be possible to provide a solid MR description for the changes, so it is easier to follow the changes, for example I am looking at this diff:

https://github.com/teemtee/tmt/pull/4661/changes#diff-f3bed0c5c8c7fcc2e8e296e3e85675c9c29c322c3a66f8def8f1d6d6d8dce260

And I would like to understand why this was changed, I would expect it would be mentioned that this is one of the improvements made to support full recipe loading ... (or something similar)

[happz]

Eh, it's still far from satisfactory, but that's not @therazix's fault, it's just so complex field, with a tech debt of its own. Hopefully, this wouldn't be the last patch, and together with the transition of dataclass-based containers, a lot would clear up eventually.