Consider removing Numaflow structs from e2e test

[juliev0]

Summary

The e2e test uses numaflow structs tied to whichever version of the numaflow go.mod says to import. These structs are convenient in the test for both creating and for reading in. But if there were a backward compatibility problem between the version of numaflow being run by the test (the test is running 2 different versions) and the structs, the test could fail.

---

Message from the maintainers:

If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.

[juliev0]

Thinking of what could possibly go wrong....

When we create the numaflow CRs, we use the numaflow struct and we convert it into an Unstructured that we can embed into our Rollout object. When we do that:

1. we could add a field that Numaflow doesn't recognize
2. we could fail to add a field that Numaflow requires, which could cause a validation failure
3. we could add a field whose type is now different, which would Numaflow to fail to read in the struct (I think?)

When we read the struct back in in the test:

1. we could try to read a field whose type is now different, which would cause the test to fail where we convert the map to numaflow spec and status structs

Given that Numaflow is trying to be backwards compatible, we could consider an approach in which we simply try to update our go.mod to reference to match one of the Numaflow versions being tested, and always test 2 versions that are from the same minor release.