Extend fuzz-tests for API conversion

[sbueringer]

Quoting @mdbooth from Slack

We recently discovered in CAPO a couple of classes of error in the way we were doing API version conversion from our currently release API version to the soon-to-be-released version. The errors were around how we restore data from lossy conversions using the annotation. Specifically, the errors were:

• We could restore old data which had been modified during up-conversion, resulting in data loss
• We could try to restore data to a struct whose parent had been deleted during up-conversion, resulting in a panic

We already run the incredibly useful CAPI fuzz tests, but they weren't sufficient to exercise these bugs so I wrote some more based on the existing ones: https://github.com/shiftstack/cluster-api-provider-openstack/blob/issue1606/test/helpers/fuzz_mutate.go
These aren't merged in CAPO yet, but I'm wondering if folks would be interested in adding them alongside the existing tests in https://github.com/kubernetes-sigs/cluster-api/blob/main/util/conversion/conversion.go.

I would keep the tests separate as here, so you'd have to call the new tests explicitly. The reason for this is that they're highly likely to find bugs for non-trivial API conversions, and these bugs can be extremely difficult to fix. It wouldn't be desirable to force users of the existing fuzz tests to fix them all before version bumping CAPI.

xref: https://kubernetes.slack.com/archives/C8TSNPY4T/p1691583086419469

I think this would be a great addition to our tests

[sbueringer]

/triage accepted
/cc @mdbooth

[mdbooth]

CAPO reference: kubernetes-sigs/cluster-api-provider-openstack#1626

I'm hoping this is getting close to merging, btw. I don't think the tests are likely to change again.

[fabriziopandini]

/kind feature
/priority important-longterm

[mdbooth]

@fabriziopandini I wonder if these might better live in controller-runtime? They seem quite generic.

Related: I'd also like to cleanup and document the CAPO API conversion restore code so it can be more easily used elsewhere: https://github.com/kubernetes-sigs/cluster-api-provider-openstack/blob/main/pkg/utils/conversion/restore.go

[sbueringer]

Not sure. The entire conversion annotation mechanism is Cluster API specific

[mdbooth]

Not sure. The entire conversion annotation mechanism is Cluster API specific

The name of the annotation is just a string, and actually something I need to fix anyway. An issue with it is that we currently assume the version the prior annotation refers to is either the hub or the spoke, but it doesn't have to be, e.g. during an upgrade.

[sbueringer]

I meant if CAPI is the only one using that annotation and an implementation like that is not very widespread, I don't know if other folks using CR have a chance to get the fuzz tests green (which is an issue in itself, but not only about upstreaming the fuzz testing)

I honestly don't know how other folks make sure they don't lose data on round-trips