Feature openapi_extensions with helper functions for JSON responses and requestBodies

[erewok]

Following our discussion on adding some helper functions for documenting a JSON requestBody or response, this PR includes the following, all gated by the feature-flag suggested in the discussion, openapi_extensions:

• New Trait RequestBodyExt for easily documenting JSON requestBody content (implemented for RequestBodyBuilder ).
• New Trait ResponseExt for easily documenting JSON response content (implemented for ResponseBuilder).
• Includes tests for new traits and methods
• Includes documentation for these traits

In addition, the following changes are also included:

• Adds from_response_name for Ref struct for "#/components/responses/SomeObject" references
• Adds -F openapi_extensions to cargo tests github actions workflow

Questions

Having traits in this case may be unnecessary because these methods are only implemented in each case for a single struct. We could do one of the following [with these traits]:

• Create a single trait that is shared by RequestBodyBuilder and ResponseBuilder (instead of two separate traits). The trait could include common shared things, but may result in people using response objects in requests or otherwise blending the two different types. (A single shared trait is originally how I did this in my own project.)
• Drop the traits and implement these as methods directly on RequestBodyBuilder and ResponseBuilder.
• Alternatively, I could keep the two new traits but also implement RequestBodyBuilderExt (probably renaming the trait) for RequestBody and ResponseBuilderExt for Response (also renaming the trait) instead of just for the builders and then having traits would probably be justified.

Happy to implement one of the above or leave this as-is. Also, happy to take any feedback or make any changes requested.

[juhaku]

• Create a single trait that is shared by RequestBodyBuilder and ResponseBuilder (instead of two separate traits). The trait could include common shared things, but may result in people using response objects in requests or otherwise blending the two different types. (A single shared trait is originally how I did this in my own project.)
• Drop the traits and implement these as methods directly on RequestBodyBuilder and ResponseBuilder.

I think the two seprate traits are good since then it allows having possible separete set of helpers for each type which is a good thing for separating consern.

• Alternatively, I could keep the two new traits but also implement RequestBodyBuilderExt (probably renaming the trait) for RequestBody and ResponseBuilderExt for Response (also renaming the trait) instead of just for the builders and then having traits would probably be justified.

Yeah these could be implemented for Response and RequestBody as well thus naming the traits as ResponseExt and RequestBodyExt is reasonable.

[juhaku]

This looks awesome 👍 can't wait to get more utilities to the library.

[erewok]

Sounds great, @juhaku! Thanks for the suggestions.

I have now made the changes discussed above:

• Rename traits: ResponseExt and RequestBodyExt
• Implement RequestBodyExt for RequestBody
• Implement ResponseExt for Response

I think this PR is ready for one more review and if you are satisfied with it, we can merge. Alternately, I am happy to make any other changes you would prefer.

[juhaku]

Super. 🥇