Refactor GenericMap to prevent managedField issues

[njhale]

This change lets us generate the correct OpenAPI schema for GenericMap without the need to mutate the schema for fields, by name, at runtime. It will stop the "managedFields" message from being printed for preexisting usages of GenericMap and prevent it for all new usages going forward.

[njhale]

Looks like I'm still having some issues here. Will update.

[njhale]

OK -- this is all ready to go

[ibuildthecloud]

Since this is a pointer everywhere I feel like the chance of panic is extremely high. Like I'm reading all the changes and trying to see if you first checked for nil. What if you add a GetData() to GenericMap that will first check if the receiver is nil and then return nil. So then existing code that did foo.DeployArgs and just be changed to foo.DeployArgs.GetData() and still be safe.

[njhale]

I like this. Added.

[njhale]

The integration tests are failing in a way that makes it hard to tell what the exact problem is. TestServiceInfo fails on line 30 with:

 #5 DONE 0.0s
time="2023-09-04T03:16:12Z" level=error msg="apiserver received an error that is not an metav1.Status: &errors.errorString{s:\"failed to find image information for nested acorn [nested]\"}: failed to find image information for nested acorn [nested]\n" error="<nil>"
    services_test.go:30: App.api.acorn.io "divine-moon" is invalid: spec.image: Invalid value: "2eb7bb425cf1072e11a12b3a822d29ae019f38994a15e8be54b2b8bea66eb394": failed to find image information for nested acorn [nested]

when attempting to run an Acorn built earlier in the same test

I know that it must be happening client-side since I'm executing the test in my branch against a local instance running runtime:main. Unless I'm missing something obvious, I suspect there's some issue with marshaling and/or marshaling GenericMap that silently breaks the build|run. I haven't managed to pin down exactly where this is happening yet though.

[njhale]

This is all ready for review. Thanks for the patience folks.

[njhale]

I don't really like the way this looks. Any suggestions?

[njhale]

This was added to satisfy a preexisting requirement in the code that depends on equality between the zero value of v1.GenericMap and nil; when we switched from a named map type to a struct, the default logic provided by equality.Semantic was no longer sufficient.

[tylerslaton]

Have you tried integrating this into manager and seeing what happens?

[njhale]

Have you tried integrating this into manager and seeing what happens?

I've smoke-tested the backwards and forwards compatibility in runtime, so this should work just fine. A PR for manager using this branch is on its way.