Remove `exceptions.go`

[jmcarp]

In most cases, our codegen logic derives go types, methods, etc. purely from the openapi spec. However, in a few cases, we need to provide hints to change the default behavior, captured in https://github.com/oxidecomputer/oxide.go/blob/main/internal/generate/exceptions.go. We should gradually remove cases from this file and eventually drop it entirely. Instead, we can either change the nexus api to behave consistently, or expose openapi extensions from nexus to provide codegen hints in exceptional cases. This will allow nexus to control how the sdk is generated, rather than building hidden knowledge about nexus into the codegen logic here.

By the way, I was looking at exceptions.go and didn't fully understand the overrides we've defined there. For example, we configure a few specific types to serialize using omitzero rather than the default omitempty. We said in the PR description that the goal was to serialize empty slices of those types to [] instead of omitting, but I think changing from omitempty to omitzero actually has the opposite effect. @sudomateo do you have context for that change?

[sudomateo]

Thanks for writing this up @jmcarp!

There will always be some need for ad-hoc exceptions, but I agree that we should work to eliminate execptions.go and move these exceptional cases into the OpenAPI specification where possible. It's likely we'll get to a point where the SDK logic is robust enough to handle these edge cases after we finalize RFD 0614 and implement the changes within.

The omitzero and omitempty distinction is a bit confusing and, quite frankly, annoying. I won't exhaust the differences across all Go types, but for slices specifically the behavior is:

omitzero

• nil -> omitted
• []T{} -> []
• []T{a, b, c} -> [a, b, c]

omitempty

• nil -> null
• []T{} -> omitted
• []T{a, b, c} -> [a, b, c]

The VPC firewall rules update API expects the rules attribute to be required and not nullable, so our previous use of omitempty was incompatible with the API.