Allow multiple expected measurements per register

[bakhtin]

📝 Summary

Allow multiple expected measurements per register with expected_any. Retain backwards compatibility where expected only allowed a single string value.

⛱ Motivation and Context

Measurements on Google Cloud Platform vary depending on the region/instance size. It yields multiple combinations of the RTMR0 register while others remain the same. Allowing to put a measurement with multiple values in the single register improves the UX of the operator. Instead of putting all possible combinations with varying RTMR0 one only need to allowlist a single measurement, builder-hub will allow any matching value from the list.

📚 References

---

✅ I have run these commands

• make lint
• make test
• go mod tidy

[Copilot]

Pull request overview

This PR extends the measurement validation system to support multiple expected values per register while maintaining backwards compatibility with single-string values. This enhancement addresses the need to handle varying measurements on Google Cloud Platform where different regions/instance sizes produce different RTMR0 values.

Changes:

• Modified SingleMeasurement.Expected from a single string to a list of strings with OR semantics
• Added custom JSON marshaling/unmarshaling to preserve backwards compatibility
• Updated measurement validation logic to check if actual values match any of the expected values

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
domain/types.go	Added custom JSON marshal/unmarshal methods to support both single string and array formats for the Expected field
domain/types_test.go	Added comprehensive test coverage for JSON serialization and backwards compatibility
application/service.go	Updated validation logic to check against multiple expected values using new helper function
application/service_test.go	Added test coverage for multi-value validation scenarios
httpserver/e2e_test.go	Updated test data to use array format for expected values
adapters/database/service_test.go	Updated test data to use array format for expected values
testdata/get-measurements.json	Updated test fixture with example of multiple expected values
README.md	Added documentation explaining the new multi-value format and backwards compatibility

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This example shows a single-element array, which according to the custom marshaling logic would be serialized back as a single string. Consider adding a second value to better demonstrate the multi-value capability, or add a comment explaining that single-element arrays are also valid.

Suggested change

	"expected": ["ea92ff762767eae6316794f1641c485d4846bc2b9df2eab6ba7f630ce6f4d66f"]
	"expected": ["ea92ff762767eae6316794f1641c485d4846bc2b9df2eab6ba7f630ce6f4d66f", "def456..."]

[metachris]

I don't love that we need to add custom unmarshalling logic to deal with the type overload. What do you think about it, and would this make it worth using a separate field instead?

[bakhtin]

replaced the implementation with the new field instead (expected_any)