Imaginator: add flag to by default inherit computed files, filters and triggers.

[narendraReddy45]

Description & Motivation

This PR introduces -enableDefaultInheritance flag to imaginator and builder-tool. When this flag is enabled, child images inherit triggers, filters and computed-files from sourceImage without need of empty .add files

This also maintains backward compatibility for existing image manifests functionality

Behavior matrix

Note: "metadata file" below refers to filter , computed-files or triggers

Child Manifest Directory state	Without Flag ( Default / Backward Compatible )	With -enableDefaultInheritance Flag
Neither file nor .add file is present	Empty Child has no metadata.	Inherits Child inherits metadata exactly as defined in base image.
File exists but is empty and valid	Empty Child has no metadata.	Empty Child has no metadata.
File exists with content	Replaces Child uses its own metadata.	Replaces Child uses its own metadata.
.add file exists	Merges Child appends rules to base metadata	Merges Child appends rules to base metadata

Fixes #247

Type of Change

• New feature (non-breaking change which adds functionality)
• Documentation update

How Has This Been Tested?

• Build images with tests cases as described in above behavior matrix

Testing Approach

Build images using local imageserver, imaginator, builder-tool and verify files based on test cases for desired results

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works

[rgooch]

I was not expecting changes to cmd/builder-tool. Requiring the user to make this choice/be aware of the issue negates the benefit. This should just be an option for cmd/imaginator.
The thinking is that the current behaviour is actually a bug/inconsistency, and we should fix that bug, but do so with a global flag set by the Imaginator administrator, so that they can take responsibility for any potential problems.

[narendraReddy45]

I was not expecting changes to cmd/builder-tool. Requiring the user to make this choice/be aware of the issue negates the benefit. This should just be an option for cmd/imaginator. The thinking is that the current behaviour is actually a bug/inconsistency, and we should fix that bug, but do so with a global flag set by the Imaginator administrator, so that they can take responsibility for any potential problems.

Yes, enableDefaultInheritance is intended to be an Imaginator-only admin flag to control this behavior. The reason I also added it to builder-tool is because of the build-from-manifest subcommand in builder-tool, which is used to replicate Imaginator behavior locally. Exposing the flag there allows users to reproduce the same behavior during local builds and debugging, while the actual behavioral control still remains with the Imaginator administrator.

Updated flag description to reflect the intended behavior in builder-tool

[rgooch]

This is a change to the API behaviour which may cause surprises elsewhere. There's a general pattern in the repository where an empty slice is treated differently than a nil slice (see for example filters). Please revert this piece and adapt the caller if a nil slice could cause problems.

[narendraReddy45]

Moved the existence check to the caller for correct evaluation while maintaining backward compatibility and avoiding API changes.

A different approach is required here because the return type is a slice, unlike the pointer-based return types used in triggers and filters.

[narendraReddy45]

@rgooch If enableDefaultInheritance is enabled, sparse child images whose base image is non-sparse will inherit the base filter and effectively become non-sparse.

There is currently no way for such a child image to explicitly remain sparse. An empty filter file results in an empty filter (full coverage), whereas sparse behavior is represented by a nil filter.

Should we introduce a mechanism to explicitly preserve the nil/sparse state, or is this an acceptable trade-off of enabling inheritance?