Move axum-extra's Query type to axum

[jplatte]

From #1041 (comment)

I just came across this alternative Query impl and I was wondering: is there is a downside to making this implementation the default in axum itself? are there plans to eventually do that?

As the creator of the underlying crate I may be biased a bit. There's probably some cases where it's a tad slower but that should be everything in terms of downsides.

[Lachstec]

Was also unaware of it, but I think that the version in extra is really nice and would have been very useful to me in the past.

[jplatte]

Wdyt @yanns @mladedav ?

[yanns]

I've never used the Query myself, so take my input with this in consideration.
The new query is looking good, and I don't see any reasons not to use it.

Should we add more tests, especially concerning encoding of special characters in the values?

[manortec]

I think the Query and Json modules have similar uses and importance. I think Query should be consistent with Json, so their file locations should be in the same place.

[jplatte]

cc @SabrinaJewson - do you have an opinion on this?

[SabrinaJewson]

It seems fine to me in principle. I wonder if the inefficiencies could be avoided by lazily parsing the input? That is, by default no IndexMap is generated, but if the Deserialize implementation calls deserialize_seq or deserialize_option it will scan ahead and build the map?

[jplatte]

IIRC something like that is already the case. I have some benchmarks in the repo and it's barely slower (needs some extra branches only) for cases supported by both crates.

[jplatte]

@Turbo87 since you've been involved with the query stuff, wanna make a PR for this? Both Query and Form should be copied from axum-extra to axum, and either removed or deprecated in the original place. (though note that it could conflict with #3088)

[Turbo87]

I'm wondering whether we should address jplatte/serde_html_form#23 first.

From what I've seen so far the two query extractor seem to behave slightly differently in that regard, and it would be unfortunate to introduce a breaking change twice if we think about aligning the two implementations again anyway.

[jplatte]

Oh! I didn't think my crate had different behavior in any case supported by serde_urlencoded, but I think you're right that that's different. I don't think your PR has the right approach but it will take me some time to formulate my thinking in detail.

Given all that, the best solution is probably to ship 0.8 without this.