Allow to define expected values in fields definitions

[jsoriano]

What does this PR do?

Add expected_values to fields definitions.

Why is it important?

This setting would be used in some packages to override values in ECS definitions (see elastic/elastic-package#1472).
It can be used in general to define expected values.

Checklist

• I have added test packages to test/packages that prove my change is effective.
• I have added an entry in spec/changelog.yml.

Related issues

• Closes Tests fail due to ECS expected values elastic-package#1472.

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 2e1420b

History

• 💚 Build #259 succeeded 8b01ed9

cc @jsoriano

[chrisberkhout]

Thanks for the quick action on this!

I rebuilt elastic-package with this and it did let me define my own expected_values, as in the test. I also tried expected_values: [] (expecting it to allow any values) and that failed with:

file "...fields.yml" is invalid: field 0.expected_values: Invalid type. Expected: array, given: null

I'm not familiar with the steps between the spec and the validation, but I think an array of strings specified in JSON Schema can be empty if it doesn't also have a minItems constraint.

As mentioned elsewhere, I found a different workaround for my immediate issue.

[jsoriano]

Thanks for reporting your finding, I have created an specific issue for that, it may be a general problem with arrays #630

Apart of the validation issue we may need to review how elastic-package combines these settings, as this is currently based on length checks: https://github.com/elastic/elastic-package/blob/9d8ce35eb3051b832057b37e75ad454e28069ee6/internal/fields/dependency_manager.go#L349