Generate enum types from schemas in paths

[AlainODea]

If defining types in the schema within the parameters, responses, or requestBody within the paths of the spec, generate enums for them.

Also gather deeply nested enums in component responses or requestBodies.

Fixes #399 #467 #513 #626

[AlainODea]

In retrospect, this breaks some subtle things that don't appear to have functional impact. internal/test/strict-server/client/client.go generates internal/test/strict-server/client/client.gen.go and it ends up with this strange diff after my change (dropping a useless Empty type in place of Reusableresponse):

diff --git a/internal/test/strict-server/client/client.gen.go b/internal/test/strict-server/client/client.gen.go
index 6c02ddf..7ddcd94 100644
--- a/internal/test/strict-server/client/client.gen.go
+++ b/internal/test/strict-server/client/client.gen.go
@@ -22,8 +22,8 @@ type Example struct {
        Value *string `json:"value,omitempty"`
 }
 
-// Reusableresponse defines model for reusableresponse.
-type Reusableresponse = Example
+// Empty defines model for .
+type Empty = int
 
 // MultipleRequestAndResponseTypesTextBody defines parameters for MultipleRequestAndResponseTypes.
 type MultipleRequestAndResponseTypesTextBody = string

[AlainODea]

This doesn't quite solve #626, as in this case we get a:

// N200Health defines model for 200.Health.
type N200Health string

Whereas I'd expect a struct

Good catch! I had missed that. I'll take another shot at this and see where I can get.

Thank you for the code review.

[jamietanna]

@AlainODea no worries! Mind marking this as a draft?

(I've also spotted that there may be cases where we're not (in the existing code) generating enums from nested objects - I'll try and get an issue raised for it soon)

[discordianfish]

Are you still working on this? Would be great to see this fixed.

[AlainODea]

Are you still working on this? Would be great to see this fixed.

I would love to. Unfortunately, my immediate need for this has passed and I'm swamped with other priorities at work.

There are a number of related PRs like Jamie's that take a more methodical approach to expanding support for types outside of schemas.

In the meantime, the best approach might be to manually or automatically transform the OpenAPI specs you need by moving things to schemas.