Create custom matchers for internal/testtypes

[killianmuldoon]

Detailed Description
Composable custom matchers should be created in order to test whether the outcome of reconciliation or other action is as intended while ignoring fields in the resulting objects that aren't of interest.

Examples

• The Kubernetes testing FakeClient currently adds a resourceVersion to objects on creation. This can cause raw comparison checks to fail. Other Metadata fields handled by the API server - creation time, generation etc. are similarly not of interest most of the time when comparing objects.
• Integration tests involve the creation of large nested objects with references to other objects. Some of these objects, e.g. templates, may undergo mutation during reconciliation which isn't of interest to the comparison for the test. In the case of templates they may be rotated and so have a new, unpredictable generated name. Matching should be possible based on characteristics specified in either an allowlist or a blocklist.

The target use case for these matchers is in testing, and initially for the controllers/topology package. These matchers should be placed in the internal/testtypes package.

This issue is being worked on in parallel with #5137 and a short discussion about the custom matchers is here

/kind feature

[killianmuldoon]

/area testing
/area topology
/assign

[fabriziopandini]

Other use cases to be considered:

• Real API server setting uid, creation timestamp, etc. etc.
• Webhooks applying defaults
• Controller setting status (and in some cases spec), labels, annotations or finalisers

[vincepri]

/milestone v0.4

[killianmuldoon]

Fixed by #5259