Changes "void_value" into "no_body" for req/responses with no body

[swallez]

Follow-up to #391 (comment)

This PR changes the way we represent no-body responses (and requests) in schema.json:

• the body property is now required
• it can now be a NoBody in addition to the existing PropertyBody | ValueBody
• the void_value value kind has been removed (it doesn't make sense for a property to be of type void)

We also formalize the the close relation between body type and inheritance: when a request or response extends a class, the parent class defines body properties inherited by the child class. The child class therefore has to have a PropertyBody.

The body is required in the schema but is still optional in the spec (ultimately we should enforce it), and a simple heuristic is used to find the correct body type when it's not present in the TS spec:

• if the request extends a parent class, the body is set to a PropertyBody with an emptu list of properties
• otherwise it is set to NoBody

New validations verify this.

Aside:

The only exception to the above is RequestBase which is actually a marker class that also links to the CommonRequestParameter behavior. IMHO we should get rid of RequestBase entirely and have requests directly implement the behavior. This is out of scope of this PR.

There are changes in the schema with the new body type, but the TS output has no change except some formatting that is a side effect of body now being required.

[delvedor]

Great work! I've left a couple of notes.

[philkra]

Can we also directly add a specific Response class to extend from in no body cases? Thanks in advance

[swallez]

@philkra

Can we also directly add a specific Response class to extend from in no body cases? Thanks in advance

Unfortunately no. Parent classes in responses are regular interfaces and not responses (i.e. they don't have this nested structure with body) and so can only be used to defined body properties that are shared among responses extending them.

[delvedor]

LGTM