feat(go): Improve dynamic snippets error reporting

[amckinney]

This adds the ErrorReporter into the dynamic snippet generator's core flow. With this, we collect all errors that occur during snippet generation, but continue to compose the snippet as best we can (leveraging go.TypeInstantiation.nop as needed).

In the future, we plan to supplement this validation with the help of JSON schema, but this at least builds out the hand-crafted solution that will be used by the regions of the snippet that won't be covered by JSON schema (e.g. query parameters, headers, etc).

[github-actions]

🌿 Preview your docs: https://fern-preview-43bc088e-c9fe-4854-a77f-c0c2e1a9b226.docs.buildwithfern.com/learn

[dsinghvi]

${JSON.stringify(discriminantValue)} this might be a little tough for anyone to render in a pretty way -- maybe we just add the type of discriminantValue ?

[amckinney]

Good call, happy to adjust the message here.

[dsinghvi]

Approving to unblock, couple things crossed my mind:

1. If we add JSON.stringify() in the error messages, its going to be hard for a consumer to render in a pretty way.
2. It would be nice to decouple validation from generator specific code (i.e. python/typescript should not have to worry about dealing with validation)
3. Reimplementing validation will never be as fully-featured as a third party lib that'll take things like min, max, regex into account as well (so still pushing json schema here)

Still great to have this since we are going from a world with no validation to real validation. Curious for your thoughts on the above!

[amckinney]

... couple things crossed my mind:

1. Good call - i'll see what I can do to remove all instances of JSON.stringify in the error messages before merging.
2. Another good call - we should be able to do this by pushing more logic into the to-be-named AbstractDynamicSnippetsGeneratorContext that will be shared between all dynamic snippet generators. I'll keep this in mind once we start rolling out the next dynamic snippets generator.
3. 100% agree, this won't replace the JSON schema validation we have planned.
   • I imagine the final flow will be receive request -> validate against JSON schema -> generate snippet and collect warnings along the way.
   • Many (if not all) of the "critical" errors we define here can be factored out and only warnings that can't be easily captured by JSON schema will remain from this abstraction.