schemagen: parity between cue and protoc implementations

[sam-heilbron]

At the moment, solo-kit exposes 2 ways of generating open api schemas from proto definitions. Context around this feature can be found in the PR that introduced it: #421.

We are prevented from using the cue implementation in Gloo Edge, due to the following reason (extracted from #421 PR description):

---

This is our preferred implementation. It is not used in production yet, due to some performance issues with the Gloo Edge API. However, our goal is to eventually migrate our code to rely on this implemenation. I added in this code in this iteration so that we could compare the generated schemas between the implementations.

cuelang/cue#944 tracks the issue we face when using cuelang with the Gloo Edge API. Specifically, as more oneof's are added to the API, the performance degrades dramatically, to the point where it takes longer than 15 minutes to generate schemas. The authors are aware of this issue and are actively working on improving it. Until it is resolved, we cannot move forward with this implementation.

This is the pattern that skv2 relies on (https://github.com/solo-io/skv2/blob/master/codegen/render/manifests_renderer.go) and is loosely based on an istio tool cue-gen (https://github.com/istio/tools/tree/master/cmd/cue-gen). These API's don't have the same number of oneof's as Gloo Edge and therefore don't face the same performance degredation.

---

Over time, we have added features to the protoc implementation that are not included in the cue implementation. When we eventually use cue in solo-kit, we need to ensure feature parity. Below is a list of changes we'll need to support in cue:

• Support description truncation (schema-gen: support description truncation and int64 primitive type #431)
• Support int64 support (schema-gen: support description truncation and int64 primitive type #431)