Support local `source` for `requires.input` (align with package-spec `package_requirement`)

[teresaromero]

Part of #3277.

Summary

Implement local resolution for required input packages so a composable integration and its input packages can be developed in the same repository without publishing to EPR first.

This is the follow-up tracked from PR #3459 review

Spec alignment

Package spec defines package_requirement as a oneOf:

• package + version → exact version from the registry, or
• source → relative path to the source of the required package, which overrides downloading that package from EPR for tests.

Reference: config.spec.yml — package_requirement.

For elastic-package, we want the same override idea for the build/install path: when source is present for a required input, resolve that path (relative to the integration package root) and use it instead of DownloadPackage from the registry.

Current behavior

• RequiredInputsResolver.mapRequiredInputPackagesPaths in internal/requiredinputs/requiredinputs.go only downloads via the EPR client.
• openPackageFS already supports directory and zip once a filesystem path is available.

Scope / acceptance criteria (proposal)

1. Model: Extend requires.input dependency representation (e.g. internal/packages.PackageDependency) so each entry can be either { package, version } or { source }, consistent with package-spec’s package_requirement oneOf (mutually exclusive; validate errors if both or neither where inappropriate).

2. Resolve source: Interpret source as a path relative to the composable package root (same spirit as spec: relative path to required package source). Resolve to an absolute path, then either use it as a built package directory/zip or build the input package from source into a temp output if the path is source (team decision: require pre-built vs auto-elastic-package build).

3. Wire into resolver: mapRequiredInputPackagesPaths (or equivalent) chooses EPR download vs local path per entry; downstream bundling unchanged aside from the map values.

4. Spec / publishing: Ensure published manifest.yml behavior remains sane (e.g. source only for local dev, stripped or disallowed in published artifacts if required)—coordinate with package-spec if manifest.yml schema for requires.input must be updated to include source.

5. Tests: Add coverage with a fixture under test/packages/ or test/manual_packages/ that uses source and does not hit EPR for that dependency.

Related code

• internal/requiredinputs/requiredinputs.go — mapRequiredInputPackagesPaths, openPackageFS, Bundle
• internal/packages/packages.go — PackageDependency, Requires.Input
• cmd/build.go (and other commands that construct RequiredInputsResolver) — may need profile/registry only when source is absent

cc @jsoriano (original review)

[teresaromero]

Adding scope to this issue is a full support for package testing on composables, feedback comments from original PR

• Support building integration packages with required input dependencies #3459 (comment)
• Support building integration packages with required input dependencies #3459 (comment)
• Support building integration packages with required input dependencies #3459 (comment)
• Support building integration packages with required input dependencies #3459 (comment)

[teresaromero]

@jsoriano the source reference, will it be the direct source to pick the bundle files, or should this package be built too prior to do the build of the composable at tests? i was asuming the source was the filesystem (fixture) where the bundled files where picked up, these files are not changed during build, so it wont make a difference to use the build bundle of the input or the source? just asking for clarity. thanks!

[jsoriano]

As the source files are available, I see two options:

• Build the whole required package/s before building the composable package.
• Directly take the needed source files from the source package, and process them if needed.

The first option is slightly more inefficient, as whole packages are built even if not always needed, but once the package is built, the process is the same as with packages downloaded from the registry.

So yes, I'd say that we build the local required packages before building the composable package.