Document more complex parameters in actix plugin

[platy]

Attempt at fixing #239 and #265

For usage of serde_qs::QsQuery<T>, this will descend the tree of T and document each primitive or array as a separate parameter with the name given by it's location in the tree in the qs format, eg. user[phone_number][mobile]. The main limitaion is that an array cannot contain an object, only primitives - this is because an array of primitives can be identified without array indicies which would require a parameter in the name - and openapi doesn't support that.

For other parameters this change also adds the .items parameter of the ParameterObject and is generated recursively.

[wafflespeanut]

Nested parameters can go beyond one level in schema, so it's better if we probably leave it at items: v.items.clone()?

[platy]

Here v.items is Option<DefaultSchemaRaw> rather than Option<Items> so it needs to be mapped.
I thought that this part of the code was only being used to produce items for query / path parameters in which case nested items would only work with different values for collection_format so that will need to be specified somewhere.
I think we need collection_format before this can be merged.

[platy]

Now that I have read the documentation of serde_qs a bit better I see what you mean, nesting in queries is not something I have used.
The openapi v2 spec doesn't allow for objects in query parameters so the definitions generated for serde_qs will need to create a separate parameter for each nested field. I will have a try at this serde_qs-specific generation

[omid]

One issue which seems not related to your changes... If I don't have any dependency on serde_qs in my own package, it will trigger an error like:

  --> /usr/local/cargo/git/checkouts/paperclip-a2bfe9987995ca28/f053346/core/src/v2/actix.rs:22:15
   |
22 | use serde_qs::actix::QsQuery;
   |               ^^^^^ could not find `actix` in `serde_qs`

I think it's because we don't have the actix feature enabled in the serde_qs dependency definition.
Currently in serde_qs we have actix and actix2 features. I think the equivalent feature should be applied here.

[omid]

The version of serde_qs in the core is 0. It means at some point in time, tests may pass, but the code can be broken.

[platy]

@omid thanks for the feedback, I'll get around to trying to fix these things tomorrow. I'm a bit confused about what to do about the dependencies. I guess that maybe we should reexport QsQuery like with the actix::web stuff.

[omid]

@omid thanks for the feedback, I'll get around to trying to fix these things tomorrow. I'm a bit confused about what to do about the dependencies. I guess that maybe we should reexport QsQuery like with the actix::web stuff.

We can fix this dependency problem in another PR @platy.
I have the environment prepared for this, maybe I can do that :)

[platy]

So afaics we cant specify the actix / actix2 features on serde_qs without splitting the serde_qs feature into 2, ie. serde_qs+actix2, serde_qs+actix3. Which doesn't seem worth it.

[platy]

I'm now not convinced that the QS array serialisation can actually be expressed in OpenAPI. I tried out a JS client generator using the spec generated by this branch and it url-encodes the brackets, which serde_qs doesn't accept by default.

So I'm making this a draft again.

[platy]

I've raised another PR #278 which just has the items and not the QS stuff which I don't think will work