Determine how to create artifacts for testing candidate validation

[edwardmack]

Issue summary

For the candidate validation subsystem to validate it requires the following artifacts to preform the validation:

• persisted validation data
• validation code
• candidate receipt
• proof of validity (PoV)

I order to confirm that the candidate validation subsystem is performing correctly we need to test is with different versions of the above artifacts. This issue is to determine how to gather these pieces for testing different scenarios. Research will include:

• Reviewing other systems (polkadot) to see how they are testing these, and if there is a test harness or simulator that exists that can produce these artifacts.
• Determine if it's feasible to manually generate these for testing
• Are there RPC calls or other API calls that can be utilized to gather existing artifacts from existing parachains to test existing artifacts.

The finding from this will determine how we'll build tests for confirming that issues #3547 and #3919 are preforming correctly.

Other information and links

[edwardmack]

Results of research: After reviewing parity's polkadot repo for examples of how they conduct tests of the candidate validation subsystem, and discussions with members on the gossamer team, and thinking about the best approach I've decided to take the following approach:

• Build helper functions in the tests that aid in constructing and signing of the candidate receipt struct and validation code.
• Manually construct structs for PoV, persisted validation data, and for simple tests the validation code.
• These structs are used directly in unit tests as well as in messages passed to this subsystem in integration/black box testing.
• These structs are normally created as the result of call made to the runtime API, or are sent to the node from other nodes, so testing regarding how these structs are created will be covered by the tests for the runtime API (when that is implemented).
• Coding differences when these are constructed make it possible to simulate and test a variety of exceptions that may occur during candidate validation.
• For cases where it was hard to simulate exceptions the structs were generated as mock objects (using go mocks)

Addressing the tests utilizing the strategies outlined above make it possible to test the system for exceptions that this subsystem may encounter. I've used the results of this research in the tests that are included in PR #4036. This issue will be closed when that PR has been merged.

[edwardmack]

Closed when PR #4036 was merged.