feat(validation)!: validation testing framework

[meganwolf0]

Description

Initial work to specify Lula-native validation testing

• Updates the previously (imo poorly) named inject function to transform - tried to do a bit of refactor to pull out functionality to support more granular tests
• Addition of RunTests method to the LulaValidation + updated schema to support
• Updated docs -> Hopefully the syntax/intended usage isn't too confusing. Added some sample tests for existing validations we have in compliance artifacts (https://github.com/defenseunicorns/compliance-artifacts/pull/151) - Will note that the one functionality not currently supported is deleting a specific list entry. Was thinking this could be a follow-on because this is already quite lengthy
• Modified the dev validate to handle --run-tests flag, and because this was getting annoying to debug a --print-test-resources that will print out the transformed resources.json to the validation directory -> This is basically just a print-to-screen implementation right now. Probably further discussion needed on dumping a test-result object or how we want to handle that.

Follow-ups to this

• probably a refactor of the dev validate cmd to support the e2e testing structure we have
• addition of --run-tests to lula validate -> will need to include some exploration/decision on how the test report gets dumped
• delete a specified list item

Related Issue

Fixes #460

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Other (security config, docs update, etc)

Checklist before merging

• Test, docs, adr added or updated as needed
• Schema Updates applied
• Contributor Guide Steps followed

[brandtkeller]

Minor comments as I look at general structure otherwise no major concerns.

[brandtkeller]

The expected result of the test - satisfied or not-satisfied

This is an interesting point as we look to clear a path for validations used outside of OSCAL. We map the result of a policy (pass/fail) to align to findings/observations using the OSCAL terminology (satisfied/not-satisfied).

We might look at what terminology OPA/Kyverno use and/or decide on what Lulas will be.

[meganwolf0]

That's fair - I initially was thinking like pass/fail - that also sort of conflates with the overall test result (which is pass/fail) so walked back the terminology. I mean it could be more like policy/provider-result -> true/false? Or accept/reject?

[brandtkeller]

Walk me through the expected result <> test result of pass/fail and how that might conflate?

Seems like pass/fail at the test result layer would align well to the expected result also being pass/fail

[meganwolf0]

Made a couple updates to incorporate the templating for dev commands work

• Added tests for the dev validate --run-tests in e2e -> Changed the logic to fail the command when --run-tests is passed and a test fails
• Change the ctx from context.Background() to cmd.Context() - I was thinking that's the context we use in lula validate so just being consistent

[brandtkeller]

nearly finished with review - no major modifications noticed as of yet.